Similar to the range-or-specific-version ambiguity of `@1.2` in the past,
which was solved with `@1.2` vs `@=1.2` we still have the ambiguity of
`name=a,b,c` in multi-valued variants. Do they mean "at least a,b,c" or
"exactly a,b,c"?
This issue comes up in for example `gcc languages=c,cxx`; there's no
way to exclude `fortran`.
The ambiguity is resolved with syntax `:=` to distinguish concrete from
abstract.
The following strings parse as **concrete** variants:
* `name:=a,b,c` => values exactly {a, b, c}
* `name:=a` => values exactly {a}
* `+name` => values exactly {True}
* `~name` => values exactly {False}
The following strings parse as **abstract** variants:
* `name=a,b,c` values at least {a, b, c}
* `name=*` special case for testing existence of a variant; values are at
least the empty set {}
As a reminder
* `satisfies(lhs, rhs)` means `concretizations(lhs)` ⊆ `concretizations(rhs)`
* `intersects(lhs, rhs)` means `concretizations(lhs)` ∩ `concretizations(rhs)` ≠ ∅
where `concretizations(...)` is the set of sets of variant values in this case.
The satisfies semantics are:
* rhs abstract: rhs values is a subset of lhs values (whether lhs is abstract or concrete)
* lhs concrete, rhs concrete: set equality
* lhs abstract, rhs concrete: false
and intersects should mean
* lhs and rhs abstract: true (the union is a valid concretization under both)
* lhs or rhs abstract: true iff the abstract variant's values are a subset of the concrete one
* lhs concrete, rhs concrete: set equality
Concrete specs with single-valued variants are printed `+foo`, `~foo` and `foo=bar`;
only multi-valued variants are printed with `foo:=bar,baz` to reduce the visual noise.
neoverse_v1 matches the name of the stack and more accurately captures
the requirement for these jobs. The relevant runners in GitLab already
bear both tags, so this shouldn't affect how jobs get assigned to runners.
* kokkos: add version 4.6.00
* kokkos-kernels: add version 4.6.00
* kokkos-nvcc-wrapper: add version 4.6.00 and update url to match kokkos releases
* kokkos: add zen4 support
Return a single scope from environment.env_config_scope
Return a single scope from environment_path_scope
---------
Signed-off-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
* e4s oneapi: upgrade to latest compilers oneapi@2025.1
* update specs and package preferences
* enable some more dav packages
* enable additional specs
* e4s oneapi: packages: elfutils does not have bzip2 variant
* e4s oneapi: packages: elfutils does not have xz variant
* e4s oneapi: comment out heffte+sycl
* comment out e4s oneapi failures
* comment out more failures
* comment out failing spec
* Revert "paraview: add patch for Intel Classic compilers (#49116)"
This reverts commit 7a95e2beb5.
We'll mark Intel Classic compilers as conflicting with ParaView
versions 5.13.0-5.13.2 instead since 5.13.3 is available and can be
built with with those compilers.
* Add conflict for Intel Class compilers and ParaView 5.13.0-5.13.2.
* paraview: add new v5.13.3 release
This commit reorders ASP setup, so that rules from
possible compilers are collected first.
This allows us to know the dependencies that may be
injected before counting the possible dependencies,
so we can account for them too.
Proceeding this way makes it easier to inject
complex runtimes, like hip.
Signed-off-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
Deal with the "issue" that passing a str instance does not cause a
type check failure, because str is a subset of Sequence[str] and
Iterable[str]. Instead fix it by special casing the str instance.
* fix: move depends_on(c,cxx,fortran) with other dependencies, after variants
* treewide style: move depends_on(c,cxx,fortran) with other dependencies, after variants
* treewide style: move depends_on(c,cxx,fortran) with other dependencies, after variant
---------
Co-authored-by: Alec Scott <hi@alecbcs.com>
Compatibility with Python 3.6 is still tested by the
rhel8-platform-python job, and Ubuntu 20.04 will be
removed soon from the list of runners:
https://github.com/actions/runner-images/issues/11101
Signed-off-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
CMake 4.0.0 breaks compatibility with CMake projects
requiring a CMake < 3.5. However, many projects that
specify a minimum requirement for versions older
than 3.5 are actually compatible with newer CMake
and do not use CMake 3.4 or older features. This
allows those projects to use a newer CMake
Co-authored-by: John W. Parent <45471568+johnwparent@users.noreply.github.com>
Signed-off-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
The requirements being removed are redundant, or
even outdated (%cray-prgenv-* is not a compiler in v0.23).
When compilers turned into nodes, these constraints,
with the "one_of" policy, started being unsat under
certain conditions e.g. we can't compile anymore
with GCC and depend on LLVM as a library.
Remove the requirements to make the recipe solvable
again.
Signed-off-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
