Concretization differs greatly when using different "prefer" syntax #51267
Description
Description
I have a large and complex environment that I have previously shared for debugging a slow concretizer (#51224). This was with gcc, and in this case it was only required to specify one compiler (gcc) and I got correct concretization results with the new spack v1 syntax for compiler preferences (no brainer, since there is only one compiler):
packages:
c:
prefer:
- gcc
cxx:
prefer:
- gcc
fortran:
prefer:
- gcc
I have since updated the reproducer to include an environment that uses Intel oneAPI as the main = preferred compiler (https://github.com/climbfuji/spack/tree/feature/reproducer_slow_concretizer_spack_v1; environment unified-env-oneapi)
When using intel-oneapi-compilers as preferred compiler, one needs a backup compiler for packages that do not build with intel-oneapi-compilers. A natural choice is gcc. Now, I have at least three different ways for specifying the preferred compiler:
v001
packages:
c:
prefer:
- oneapi
cxx:
prefer:
- oneapi
fortran:
prefer:
- oneapi
v002
# v002
packages:
all:
prefer:
- '%oneapi'
v003
packages:
c:
prefer:
- intel-oneapi-compilers
cxx:
prefer:
- intel-oneapi-compilers
fortran:
prefer:
- intel-oneapi-compilers
For all three options, the concretizer creates an environment with a minimum number of duplicate packages, as expected. Example:
[unified-env-oneapi] [dom@8W089Y3 spack-1.0]$ ~/work/spack-stack/update-to-spack-v1/spst-upd-to-spack-v1/util/show_duplicate_packages.py
{'[email protected]/uytr4veiqfln6wgqjbx3cldmpx2ted64', '[email protected]/z4j2goubtrkolcrwp7yv7juzvnnewemj'}
{'[email protected]/c72qxawdsesfqc25tunjdetvi7arl72i', '[email protected]/hpghq5vgm5fd6agvyj3brsx5uazxw3nf', '[email protected]/ljrplsinyovfwxtjfo64hk2nw6w7b64l'}
{'[email protected]/fr3hazy6zuihake6kgzgw6cngcenlaen', '[email protected]/5gsne3atte4ddckxt76c7dqndyk6be7g'}
{'[email protected]/tmafdeu6crpfhvvdliqmtiyucxqv6jdf', '[email protected]/gndeghzufcgsfiza2lgpdw5hz6xp5qlh'}
v002 (old spack v0.23 syntax) builds all but the 12 packages that I expect to be built with gcc with the preferred compiler:
[unified-env-oneapi] [dom@8W089Y3 spack-1.0]$ cat log.concretize.unified-env-oneapi.v002 | grep gcc
- dmen353 ^[email protected]~doc+ncurses+ownlibs~qtgui build_system=generic build_type=Release arch=linux-almalinux9-skylake %c,[email protected]
[e] igrmpzp ^[email protected]~binutils+bootstrap~graphite~nvptx~piclibs~profiled~strip build_system=autotools build_type=RelWithDebInfo languages:='c,c++' arch=linux-almalinux9-skylake
[e] odpfvwc ^[email protected] build_system=generic arch=linux-almalinux9-skylake
- 6iejsji ^[email protected]+optimize+pic+shared build_system=makefile arch=linux-almalinux9-skylake %c,[email protected]
- o5e2gpm ^[email protected]~guile build_system=generic arch=linux-almalinux9-skylake %[email protected]
- xjn2t6g ^[email protected]~dev~docs+src build_system=generic arch=linux-almalinux9-skylake %c,[email protected]
- xokv7og ^[email protected]~dbus~debug~doc~examples~framework~gtk~gui~location~opengl~phonon+shared+sql+ssl+tools~webkit build_system=generic patches:=2081e9c,51aeba5,75bcb42,78c70fb,7f34d48,84b0991,9378afd arch=linux-almalinux9-skylake %c,[email protected]
- bjjotbm ^[email protected]~color build_system=autotools arch=linux-almalinux9-skylake %c,[email protected]
- aoigfko ^[email protected] build_system=autotools arch=linux-almalinux9-skylake %[email protected]
- d52iv6h ^[email protected]~doc+openmp build_system=autotools arch=linux-almalinux9-skylake %c,[email protected]
- puuoklr ^[email protected]+cxx~java~pic~python build_system=autotools patches:=33897ad arch=linux-almalinux9-skylake %c,[email protected]
- khuigzj ^[email protected] build_system=python_pip arch=linux-almalinux9-skylake %[email protected]
[unified-env-oneapi] [dom@8W089Y3 spack-1.0]$ cat log.concretize.unified-env-oneapi.v002 | grep gcc | wc -l
12
v001 produces a very different environment, with 177 packages built with gcc - bad.
v003 produces another very different environment, with 144 packages build with gcc - bad.
All three concretization logs are attached: log.concretize.unified-env-oneapi.tar.gz
Questions/Findings
- v002 (old syntax) produces the best = correct results - Is it ok to keep using this for now?
- v001 and v003 do not - Is this expected? If not, can this be fixed (how)?
- v001 and v003 differ - Should they? The only difference is legacy compiler name vs new compiler name, and I would have expected the concretization to be the same for those two.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status