concretizer: option to disable compiler mixing between runtime deps by scheibelp · Pull Request #51135 · spack/spack

scheibelp · 2025-08-10T00:17:43Z

You can set

concretizer:
  compiler_mixing: false

then e.g.:

$ spack spec chai%c=oneapi ^umpire%c=gcc
==> Error: failed to concretize `chai %c=oneapi ^umpire %c=gcc` for the following reasons:
     1. Compiler mixing is disabled

(even with this setting on, mixing is allowed when a dependency is an external, and only enforced within transitive link run/tree, i.e. the root unification set)

TODOs

virtual_on_edge is not derived (or does not need to always be derived) for reused packages (so this is only guaranteed if reuse is disabled)
- (Update September 3) this is addressed (and tested) by 3a8ce4a
(it was agreed to punt this) See Compiler dependencies are not being passed to dependencies if package doesn't depend on the language #51244 and concretizer: option to disable compiler mixing between runtime deps #51135 (comment): this needs a way to allow users to set e.g. a Fortran compiler on the root even when the root doesn't depend on fortran, and then propagate that choice to dependencies that do depend on it
- Right now with this PR, if you set the fortran compiler on any dependency that needs Fortran, then all of them will be consistent (that is also true on account of the concretizer mandating 1 fortran compiler maximum, but this PR gives those semantics to C/C++ as well).

haampie · 2025-08-11T08:10:43Z

This is quite elegant 👍

Should also work in the future with LLVM-based compilers using libstdc++ as a runtime library because of how gcc-runtime is (or happens to be) modeled: it has a build dep on gcc and makes a copy of its compiler runtime libraries; there's no c, cxx or fortran dependency.

Not necessary for this PR, but maybe good to think ahead how this can be extended for other use cases:

For certain Fortran and (soon) C++ packages that produce modules, it's probably better if the package itself declares that its dependents need a matching fortran and cxx compiler resp. Is it easy to extend the rules for that? I guess a more advanced compiler_mixing rule works. Or is this too constraining for users who know what they're doing when mixing compilers?
I can imagine that users care more about a single compiler for Fortran, but don't care about mixing compilers for C and prefer reuse there. Should this option be per language? If so shouldn't the config option go in packages.yaml? Or is this just a symptom of (1) and should we only fix (1).

lib/spack/spack/solver/asp.py

lib/spack/spack/solver/concretize.lp

lib/spack/spack/schema/concretizer.py

alalazo · 2025-08-11T08:40:24Z

I'll post benchmark results asap.

…th are not external) Signed-off-by: Peter Scheibel <[email protected]>

Signed-off-by: Peter Scheibel <[email protected]>

scheibelp · 2025-08-11T16:58:24Z

Should also work in the future with LLVM-based compilers .
.. there's no c, cxx or fortran dependency.

I'm not clear how this PR would work with that change: there would still be virtual_on_edge...c/cxx/fortran even if there's no c/cxx/fortran dep? If you have a link to this PR (if it's in progress) or discussion I could read it

For certain Fortran and (soon) C++ packages that produce modules, it's probably better if the package itself declares that
... Is it easy to extend the rules for that?

For things that can't mix (i.e. where this is mandatory), package directives would be better than config (this PR is about both preference and need); I think it would be easy to generate the asp dynamically (i.e. where the ParentNode or ChildNode check against package names).

I can imagine that users care more about a single compiler for Fortran, but don't care about mixing compilers for C and prefer reuse there. Should this option be per language?

I think that would be a good extension but I think some people would still want to turn it off entirely (so the schema would support boolean or a dictionary of lang->boolean).

scheibelp · 2025-08-11T19:04:34Z

Should also work in the future with LLVM-based compilers .
.. there's no c, cxx or fortran dependency.

I'm not clear how this PR would work with that change: there would still be virtual_on_edge...c/cxx/fortran even if there's no c/cxx/fortran dep? If you have a link to this PR (if it's in progress) or discussion I could read it

I think I understand better now:

Most packages will have c/cxx/fortran dependencies
llvm will be injecting gcc-runtime in the future
While gcc-runtime will depend on gcc, it won't be a language dependency, so the check added here wont trip on X->gcc-runtime

alalazo

I benchmarked this against:

Spack: 1.1.0.dev0 (c46eebd)
Builtin repo: spack/spack-packages@e3d72e6
Python: 3.13.2
Platform: linux-ubuntu20.04-icelake

radiuss.disable_mixing_on.csv
radiuss.disable_mixing_no_disabling.csv
radiuss.develop.csv

When mixing is disabled the same spec can be 30% slower to concretize, otherwise there is no difference. For the record I had a configuration with 4 gcc and 2 llvm compilers

Grounding doesn't seem much of an issue, as it is solving in this case.

lib/spack/spack/solver/concretize.lp

scheibelp · 2025-08-22T00:51:25Z

Significant changes from earlier, for a dag like

  W
 / \
X   Y
 \ /
  Z

(All edges are link deps)

If W and Z need fortran (but X/Y don't) then I want to enforce fortran consistency between W and Z
If X/Y depend on fortran (but W/Z don't) I want to enforce matching between X and Y
- (Max: there is maximum 1 fortran compiler per dag right now)
- For the use case, if the user says W%[virtuals=fortran] oneapi that X/Y use %oneapi
I want to be able to disable matching for a given package by name (e.g. allow X to use whatever compiler it wants)

New statements added, plus tests for them (although not comprehensive)

…down to minimum infrastructure setup

…icient. Revert "bypass mutable_database entirely and strip test_disable_mixing_reuse down to minimum infrastructure setup" This reverts commit ea9f71d.

alalazo

I left a few comments. Did anybody ever worked out if there are edge cases with splicing that would not be covered?

I don't think we should deal with them here, in case there are, but it would be good to know if we have them.

lib/spack/spack/solver/concretize.lp

lib/spack/spack/solver/asp.py

lib/spack/docs/configuring_compilers.rst

lib/spack/spack/test/concretization/core.py

lib/spack/spack/test/conftest.py

alalazo · 2025-10-20T17:30:49Z

@scheibelp Am I correct if I say that this:

is meant to be fixed by #51383 and it's just the description of the PR that is slightly outdated?

scheibelp · 2025-10-20T23:50:13Z

Am I correct if I say that this:
...
is meant to be fixed by #51383 and it's just the description of the PR that is slightly outdated?

In short, I don't think so:

solver: set preferences from input specs using %% #51383 would allow propagating a preference for fortran transitively
Because of other constraints in the concretizer, Fortran already has to be consistent (even without this PR and solver: set preferences from input specs using %% #51383)
%% is a preference, so doesn't guarantee that you get the Fortran compiler you want (e.g. when %%% would cause an error)
So overall I still think this particular issue isn't resolved until %%%, which then also provides an encompassing mechanism for doing everything this PR achieves
- (But I've mentioned elsewhere I think users would like the configuration directives provided in this PR either way)

(I think it was already understood, but the problem this is referring to is if you use this PR and then say spack spec foo %X , where X is the "foo needs to use C as the fortran compiler if foo needs Fortran" syntax, the PR won't guarantee that you get C as your fortran compiler if foo doesn't actually depend on Fortran).

alalazo · 2025-10-21T06:37:21Z

In short, I don't think so:

Sure, the main question for me was if this problem is meant to be fixed in this PR (I was a bit perplexed seeing that in the TODO list). I guess we are on the same page:

This PR deals only with compiler mixing in the root unification set
Other PRs will introduce the %% and %%% syntax to solve the other issue

… suggestion from Max add test that confirms need for third compiler mixing block in concretize.lp checking to see what aspects of this new test are required update comments; update docs now that we dont identify by name/version auto style

…g anything beyond test_disable_mixing_prevents_mixing

…e of the tests for dependents

…utable_database introduced by this PR)

alalazo · 2025-10-27T16:14:49Z

I just benchmarked this against:

Spack: 1.1.0.dev0 (4743171)
Builtin repo: spack/spack-packages@dd5b0b3
Python: 3.13.2
Platform: linux-ubuntu20.04-icelake

When compiler mixing is allowed, this has no impact on concretization time for that benchmark:

radiuss.mixing-true.csv
radiuss.develop.csv

When we forbid compiler mixing, there's just a slight regression in solve time, but the total time is not affected:

radiuss.mixing-false.csv

alalazo

I think this PR is basically ready. The only polishing remaining is imo to:

Update the PR title and description
Add some default configuration for the new option to our YAML files

The last point in particular is needed so that users could know what is the default if they use:

$ spack config [get|blame] concretizer

Right now that command shows no value for concretize:compiler_mixing.

scheibelp · 2025-10-27T17:13:04Z

@alalazo I believe review requests are now addressed:

spack config blame concretizer now shows default setting (compiler_mixing: true)
Minor updates to PR description: i.e. second TODO is punted, and this applies to root unifications set

…pack#51135) You can set `concretizer:compiler_mixing:false` to ensure that any compiler assigned to a root spec will be used consistently by all of its dependencies; more generally, that all packages in the link/run DAG that includes the root will use the same c compiler, and likewise for c++ and Fortran. This setting defaults to true, i.e. this PR will have no affect on concretizations unless a user changes the configuration setting from the default. `compiler_mixing:` can also be a list of package names: in that case the named packages will be allowed to use any compiler; all other packages (including parents/children of those named packages) will need to be consistent. --------- Signed-off-by: Peter Scheibel <[email protected]>

scheibelp mentioned this pull request Aug 10, 2025

[WIP] disable compiler mismatch for link deps #48807

Closed

scheibelp changed the title ~~Disable compiler mixing~~ Disable compiler mixing between link deps Aug 11, 2025

haampie reviewed Aug 11, 2025

View reviewed changes

lib/spack/spack/solver/asp.py Outdated Show resolved Hide resolved

haampie reviewed Aug 11, 2025

View reviewed changes

lib/spack/spack/solver/concretize.lp Outdated Show resolved Hide resolved

haampie reviewed Aug 11, 2025

View reviewed changes

lib/spack/spack/schema/concretizer.py Outdated Show resolved Hide resolved

scheibelp added 4 commits August 11, 2025 09:32

Basic attempt to disable c-compiler mixing between link deps (when bo…

ed144d9

…th are not external) Signed-off-by: Peter Scheibel <[email protected]>

control mixing for fortran/cxx

6243cff

Signed-off-by: Peter Scheibel <[email protected]>

add in config option and send it to asp

5432dda

Signed-off-by: Peter Scheibel <[email protected]>

review edits

69af7dd

Signed-off-by: Peter Scheibel <[email protected]>

scheibelp force-pushed the disable-compiler-mixing2 branch from 28bc1d6 to 69af7dd Compare August 11, 2025 16:48

alalazo reviewed Aug 12, 2025

View reviewed changes

lib/spack/spack/solver/concretize.lp Outdated Show resolved Hide resolved

scheibelp added 9 commits August 21, 2025 13:23

consolidate asp clauses; add unit test

12474f6

allow individual packages to override compiler mixing enforcement

290a05f

auto style format

838bf30

partial model

83f00f1

typo fixed; model now sane

162ddb6

simplify varnames

23dcf03

allow_mixing nodes need to sever both above and below

72c4419

control mixing across siblings

bff341f

update comment

03787a3

scheibelp added 4 commits August 29, 2025 17:41

redo constraints in terms of unification sets

a9fed55

add comment

ef37f9d

intermediate work testing toolchains for applying sibling deps

d22ae67

another attempt at sibling compiler control that fails

73cbad6

white238 mentioned this pull request Aug 31, 2025

Compiler dependencies are not being passed to dependencies if package doesn't depend on the language #51244

Closed

3 tasks

scheibelp added 3 commits October 20, 2025 09:22

bypass mutable_database entirely and strip test_disable_mixing_reuse …

ea9f71d

…down to minimum infrastructure setup

Revert other attempted fix, because 68aaa64 appears to have been suff…

7644707

…icient. Revert "bypass mutable_database entirely and strip test_disable_mixing_reuse down to minimum infrastructure setup" This reverts commit ea9f71d.

merge from develop (appears to be only minor sync issue)

3875f6f

alalazo reviewed Oct 20, 2025

View reviewed changes

scheibelp added 10 commits October 21, 2025 13:33

collect asp compiler mixing logic into separate method

d2e8f95

rm test_disable_mixing_reuse_and_built2 as it is actually not checkin…

a1a8af7

…g anything beyond test_disable_mixing_prevents_mixing

reorganize rules (swap order of 2 and 3); more documentation

ab162ef

doc change: integrate note into normal flow

6d40804

augment reused_node_compiler to ensure it is a compiler

cfb640c

my new fake package depends on libelf, which changes the output of on…

5c11bee

…e of the tests for dependents

Reapply ea9f71d (revert 7644707) - see if this speeds up the tests.

31cdd7b

use fake_db_install for other mixing test (remove all references to m…

4446e99

…utable_database introduced by this PR)

my current best attempt at explaining these rules

96247cc

tgamblin changed the title ~~Disable compiler mixing between link deps~~ concretizer: option to disable compiler mixing between link deps Oct 27, 2025

alalazo requested changes Oct 27, 2025

View reviewed changes

add default config option

46d0376

alalazo changed the title ~~concretizer: option to disable compiler mixing between link deps~~ concretizer: option to disable compiler mixing between runtime deps Oct 27, 2025

becker33 approved these changes Oct 30, 2025

View reviewed changes

alalazo approved these changes Oct 30, 2025

View reviewed changes

scheibelp merged commit 856a303 into spack:develop Oct 30, 2025
30 of 32 checks passed

chapman39 mentioned this pull request Dec 17, 2025

Prevent mixing compilers in Spack versions over 1.1.0 llnl/uberenv#154

Draft

This was referenced Dec 22, 2025

Compiler mixing: always allow for externals #51795

Draft

compiler_mixing: config option applies per-language #51796

Merged

Conversation

scheibelp commented Aug 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

haampie commented Aug 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

alalazo commented Aug 11, 2025

Uh oh!

scheibelp commented Aug 11, 2025

Uh oh!

scheibelp commented Aug 11, 2025

Uh oh!

alalazo left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

scheibelp commented Aug 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alalazo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

alalazo commented Oct 20, 2025

Uh oh!

scheibelp commented Oct 20, 2025

Uh oh!

alalazo commented Oct 21, 2025

Uh oh!

alalazo commented Oct 27, 2025

Uh oh!

alalazo left a comment

Choose a reason for hiding this comment

Uh oh!

scheibelp commented Oct 27, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

scheibelp commented Aug 10, 2025 •

edited

Loading

haampie commented Aug 11, 2025 •

edited

Loading

alalazo left a comment •

edited

Loading

scheibelp commented Aug 22, 2025 •

edited

Loading