Repository: spack/spack

Issue:
Concretizer dumps debug state instead of printing conflict messgae
### Steps to reproduce

I run `spack concretize -f` and I get thousands of lines of errors when attempting to build with `gcc@9.4.0` on macOS for certain packages. But using `intel@2021.2` or `apple-clang@12.0.5` work fine.

I have a simplified `spack.yaml`:

```
spack:
  packages:
    all:
      compiler: [gcc@9.4.0]

  specs:
  - openmpi@4.1.1
  - jasper@2.0.32

  concretization: together
  view: true
  compilers:
  - compiler:
      spec: gcc@9.4.0
      paths:
        cc: /opt/local/bin/gcc
        cxx: /opt/local/bin/g++
        f77: /opt/local/bin/gfortran
        fc: /opt/local/bin/gfortran
      flags: {}
      operating_system: bigsur
      target: x86_64
      modules: []
      environment: {}
      extra_rpaths: []
```

And I set it up with:

```
spack env create myenv spack.yaml
spack env activate myenv
```

Then I run `spack concretize -f` and get the errors.

Removing `jasper@2.0.32` and only building `openmpi` works. In my real `spack.yaml` I tried various combinations of packages, and some like Jasper fail, but others like OpenMPI don't. 

I originally found this problem when I had multiple compilers in the compiler list and even though I set `packages.yaml` to use `gcc@9.4.0` every time I ran `spack concretize -f` everything was being built with `apple-clang` instead. 

Then, I removed `apple-clang` and then it choose Intel compilers until only `gcc@9.4.0` which then threw the error here.

This is new behavior from the last few months after I updated my fork with develop.

### Error message


```
spack concretize -f

compiler_supports_os("gcc","9.4.0","bigsur")
compiler_supports_target("gcc","9.4.0","broadwell")
compiler_supports_target("gcc","9.4.0","bulldozer")
compiler_supports_target("gcc","9.4.0","cannonlake")
compiler_supports_target("gcc","9.4.0","cascadelake")
...
condition(0)
condition(1)
condition(10)
condition(100)
condition(1000)
condition(1001)
...
version_satisfies("xextproto","7.1.99:","7.3.0")
version_satisfies("xineramaproto","1.1.99.1:","1.2.1")
version_satisfies("xpmem",":2.6.5","2.6.2")
...
virtual("yacc")
==> Error: Unsatisfiable spec.
```

### Information on your system

```
* **Spack:** 0.16.2-4260-0015f700b7
* **Python:** 3.7.9
* **Platform:** darwin-bigsur-skylake
* **Concretizer:** clingo
``` 

### General information

- [X] I have run `spack debug report` and reported the version of Spack/Python/Platform
- [X] I have searched the issues of this repo and believe this is not a duplicate
- [X] I have run the failing commands in debug mode and reported the output


Discussion:
@kgerheiser I'm unable to reproduce this on my machine. Can you post your site/user packages and config files (or `spack config get packages`) just to make sure something's not awry there?

My system:
```console
$ spack debug report
* **Spack:** 0.16.2-4266-fa6366a7df
* **Python:** 3.8.8
* **Platform:** darwin-bigsur-skylake
* **Concretizer:** clingo
```

Successful concretization:
```console
$ spack -e . concretize -f
==> Concretized openmpi@4.1.1
 -   7bb7nf6  openmpi@4.1.1%gcc@9.4.0~atomics~cuda~cxx~cxx_exceptions+gpfs~internal-hwloc~java~legacylaunchers~lustre~memchecker~pmi~singularity~sqlite3+static~thread_multiple+vt+wrapper-rpath fabrics=none schedulers=none arch=darwin-bigsur-x86_64
 -   lpshmbm      ^hwloc@2.5.0%gcc@9.4.0~cairo~cuda~gl~libudev+libxml2~netloc~nvml~opencl~pci~rocm+shared arch=darwin-bigsur-x86_64
 -   llruhzj          ^libxml2@2.9.12%gcc@9.4.0~python arch=darwin-bigsur-x86_64
 -   z6azqev              ^libiconv@1.16%gcc@9.4.0 libs=shared,static arch=darwin-bigsur-x86_64
 -   i2qenyp              ^pkgconf@1.8.0%gcc@9.4.0 arch=darwin-bigsur-x86_64
 -   aidbz6u              ^xz@5.2.5%gcc@9.4.0~pic libs=shared,static arch=darwin-bigsur-x86_64
 -   fg2nupk              ^zlib@1.2.11%gcc@9.4.0+optimize+pic+shared arch=darwin-bigsur-x86_64
 -   vp6ejmg          ^ncurses@6.2%gcc@9.4.0~symlinks+termlib abi=none arch=darwin-bigsur-x86_64
 -   neeivms      ^libevent@2.1.12%gcc@9.4.0+openssl arch=darwin-bigsur-x86_64
 -   nlnd35j          ^openssl@1.1.1l%gcc@9.4.0~docs+systemcerts arch=darwin-bigsur-x86_64
 -   feb37s6              ^perl@5.34.0%gcc@9.4.0+cpanm+shared+threads arch=darwin-bigsur-x86_64
 -   2ll5s32                  ^berkeley-db@18.1.40%gcc@9.4.0+cxx~docs+stl patches=b231fcc4d5cff05e5c3a4814f6a5af0e9a966428dc2176540d2c05aff41de522 arch=darwin-bigsur-x86_64
 -   kdqyusg                  ^bzip2@1.0.8%gcc@9.4.0~debug~pic+shared arch=darwin-bigsur-x86_64
 -   ny4utsa                      ^diffutils@3.7%gcc@9.4.0 arch=darwin-bigsur-x86_64
 -   vqtjrmh                  ^gdbm@1.19%gcc@9.4.0 arch=darwin-bigsur-x86_64
 -   gsye3eo                      ^readline@8.1%gcc@9.4.0 arch=darwin-bigsur-x86_64
 -   z5fkgs2      ^openssh@8.1p1%gcc@9.4.0 arch=darwin-bigsur-x86_64

==> Concretized jasper@2.0.32
 -   2tyqf4j  jasper@2.0.32%gcc@9.4.0+jpeg~opengl+shared build_type=Release arch=darwin-bigsur-x86_64
 -   grhec67      ^cmake@3.20.5%gcc@9.4.0~doc+ncurses+openssl+ownlibs~qt build_type=Release arch=darwin-bigsur-x86_64
 -   rmugyjs      ^libjpeg-turbo@2.1.0%gcc@9.4.0 arch=darwin-bigsur-x86_64
 -   yg4uomn          ^nasm@2.15.05%gcc@9.4.0 arch=darwin-bigsur-x86_64

==> Updating view at /rnsdhpc/code/_build/temp-spack-env/.spack-env/view
```
Looks like it's CMake related. If I do `spack external find cmake` then it works. Looking at the CMake package.py, it doesn't build with GCC on macOS:

https://github.com/spack/spack/blob/5b211c90f5b30dc3866b5d72185fe7ab6108ad46/var/spack/repos/builtin/packages/cmake/package.py#L149

But instead of that warning message I'm getting this strange failure. 

I also tested on another machine and was able to reproduce it.

Otherwise, when I run `spack config get packages` it  just returns my `spack.yaml`. I made sure to have a clean `~/.spack`.


```
spack config get packages

spack:
  packages:
    all:
      compiler: [gcc@9.4.0]
  specs:
  - openmpi@4.1.1
  - jasper@2.0.32

  concretization: together
  view: true
  compilers:
  - compiler:
      spec: gcc@9.4.0
      paths:
        cc: /opt/local/bin/gcc
        cxx: /opt/local/bin/g++
        f77: /opt/local/bin/gfortran
        fc: /opt/local/bin/gfortran
      flags: {}
      operating_system: bigsur
      target: x86_64
      modules: []
      environment: {}
      extra_rpaths: []
```
Ah good catch. A lot of codes fail to build with GCC on macOS (depending on the clang version):
- https://github.com/spack/spack/issues/15265
- https://github.com/spack/spack/issues/17662
- https://github.com/spack/spack/pull/16249
I still believe this is a bug. 

I understand that some things don't build with GCC on macOS, but there is some kind regression in behavior where it dumps thousands of lines of error messages and automatically chooses to build everything with a different compiler instead of just saying CMake can't be built with this compiler.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/cmake/package.py b/var/spack/repos/builtin/packages/cmake/package.py
--- a/var/spack/repos/builtin/packages/cmake/package.py
+++ b/var/spack/repos/builtin/packages/cmake/package.py
@@ -145,12 +145,11 @@ class Cmake(Package):
     variant('openssl', default=True,  description="Enable openssl for curl bootstrapped by CMake when using +ownlibs")
     variant('ncurses', default=True,  description='Enables the build of the ncurses gui')
 
-    # Does not compile and is not covered in upstream CI (yet).
-    conflicts('%gcc platform=darwin',
-              msg='CMake does not compile with GCC on macOS yet, '
-                  'please use %apple-clang. '
+    # See https://gitlab.kitware.com/cmake/cmake/-/issues/21135
+    conflicts('%gcc platform=darwin', when='@:3.17',
+              msg='CMake <3.18 does not compile with GCC on macOS, '
+                  'please use %apple-clang or a newer CMake release. '
                   'See: https://gitlab.kitware.com/cmake/cmake/-/issues/21135')
-
     conflicts('%nvhpc')
 
     # Really this should conflict since it's enabling or disabling openssl for


Test patch: