diff options
author | Todd Gamblin <tgamblin@llnl.gov> | 2020-07-21 18:48:37 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2020-07-21 18:48:37 -0700 |
commit | 0c44a9a504c9050a97b6629f38127d735daca8e7 (patch) | |
tree | 1a5adc16864eb42b02991808ae5cad082e8f5f3b /.coveragerc | |
parent | b81339cf809ea8f94931e91362a5ad83770bd8e7 (diff) | |
download | spack-0c44a9a504c9050a97b6629f38127d735daca8e7.tar.gz spack-0c44a9a504c9050a97b6629f38127d735daca8e7.tar.bz2 spack-0c44a9a504c9050a97b6629f38127d735daca8e7.tar.xz spack-0c44a9a504c9050a97b6629f38127d735daca8e7.zip |
bugfix: make compiler preferences slightly saner (#17590)
* bugfix: make compiler preferences slightly saner
This fixes two issues with the way we currently select compilers.
If multiple compilers have the same "id" (os/arch/compiler/version), we
currently prefer them by picking this one with the most supported
languages. This can have some surprising effects:
* If you have no `gfortran` but you have `gfortran-8`, you can detect
`clang` that has no configured C compiler -- just `f77` and `f90`. This
happens frequently on macOS with homebrew. The bug is due to some
kludginess about the way we detect mixed `clang`/`gfortran`.
* We can prefer suffixed versions of compilers to non-suffixed versions,
which means we may select `clang-gpu` over `clang` at LLNL. But,
`clang-gpu` is not actually clang, and it can break builds. We should
prefer `clang` if it's available.
- [x] prefer compilers that have C compilers and prefer no name variation
to variation.
* tests: add test for which()
Diffstat (limited to '.coveragerc')
0 files changed, 0 insertions, 0 deletions