We're using Spack on CentOS 7 systems. We build our things nightly
to stay on top of changes.

The recent changes in #3206 changed the names of the directories in
which our modules end up. We splice a spack tree into our users
environments with a shell script that used to refer to the Core
directory with something like this:

_APPS_LMOD_CORE_DIR=${APPS_DIR}/share/spack/lmod/linux-centos7-x86_64/Core

which worked well enough since all of our systems are x86_64.

Now I have two problems (and I'm not even using regular expressions):

1. the Core modules end up in linux-centos7-haswell but there's no
   good way for us to guess the haswell bit, it seems to be the arch
   of the system on which the system compiler was built.

   I poked around at the gcc command line a bit, but don't see any
   info about how it was built

   $ /usr/bin/gcc -dumpmachine
   x86_64-redhat-linux
   $ /usr/bin/gcc -print-multiarch
   
   $
   

2. We use the system gcc (4.8.5) to build gcc@8.2.0 and use that to
   build the rest of the things

   Unfortunately, the Core module prepends this bit onto the
   MODULEPATH:

   $ grep MODULEPATH share/spack/lmod/linux-centos7-haswell/Core/gcc/8.2.0-q5tss7s.lua
   prepend_path("MODULEPATH", "/home/ELIDED/temp/spack/share/spack/lmod/linux-centos7-haswell/gcc/8.2.0")
   

   but that directory doesn't exist, all the things that we've built
   with the compiler we built with the system compiler end up in
   linux-centos7-skylake_avx512.