* ASP-based solver: use satisfies instead of intersects
They are semantically equivalent for concrete versions,
but the GitVersion.intersects implementation is buggy
* Mitigation for git version bug
fixes#36134
This commit works around the issue in #36134, by using
GitVersion.satisfies instead of GitVersion.intersects
There are still underlying issues when trying to infer the
"reference version" when no explicit one is given, but:
1. They are not reproducible with our synthetic repo
2. They occur only when the `git.<xxx>` form of Git version
is used
Here we just work around the user facing issue and ensure
the tests are correct with our synthetic repository.
* py-pytorch-lightning: add v2.0.0
* py-lightning-utilities: add v0.8.0
* Update all PyTorch packages
* Open-CE does not yet have patches for PyTorch 2 on ppc64le
For `spack install --test=all gromacs`
* remove the `test` target from the `check()` call and just use
the `check` target, in accordance with usual GROMACS test protocol
* build the test binaries explicitly during the build phase
Additional minor updates are necessary. This change
updates the package structure to the newer format with a
separate Builder class so we can override `check()`.
However, note that additional modernization should be
undertaken with care.
This PR does 2 unrelated things:
1. It changes the encoding of the compilers
2. It tweaks the heuristic for the solves in a0d88179074f81d13a3fad629a43d86334e7f982
Both were initially motivated by trying to get a performance gain but, while 2 showed significant speed-ups[^1], 1 instead didn't. I kept it anyhow, since I think the code related to compilers is more consolidated with the new encoding and we might get some performance improvement out of it if we can base our errors on the `node_compiler(Package, CompilerID)` atoms instead of `attrs`.
[^1]: In general the changes in the heuristic brought a ~10% speed-up on the tests I did. I'll post detailed results below.
Add a warning about compilers.yaml that is triggered if there are multiple compilers with the same spec, os and
target (since they can't be selected by users with the spec syntax only).
* [openmpi] 5.0.0.rc10 onwards needs munge
This is the error you will see when munge is missing from `PKG_CONFIG_PATH`:
```
configure:63942: checking for pmix pkg-config cflags
configure:63956: check_package_pkgconfig_run_results=Package munge was not found in the pkg-config search path.
Perhaps you should add the directory containing `munge.pc'
to the PKG_CONFIG_PATH environment variable
Package 'munge', required by 'pmix', not found
configure:63959: $? = 1
configure:63966: pkg-config output: Package munge was not found in the pkg-config search path.
Perhaps you should add the directory containing `munge.pc'
to the PKG_CONFIG_PATH environment variable
Package 'munge', required by 'pmix', not found
configure:63972: result: error
configure:63974: error: An error occurred retrieving pmix cppflags from pkg-config
```
* Use same PKG_CONFIG_PATH defaults for ompi+pmix+prrte
The issue I tried to fix in https://github.com/spack/spack/pull/36105 comes from
different default search paths in different `pkg-config` executables used in
`openmpi` and `pmix` package. As these tools (`openmpi`, `pmix`, and `prrte`)
all use the same mechanisms to detect dependencies, the `pkg-config` environment
they use should also be equal.
Since GPG clear-sign cannot deal with lines longer than 19995 characters
and doesn't even error but simply truncates those linese (don't ask me
why...), we have to be careful not to hit that line limit when reducing
the filesize.
So, instead this PR sets the indent level to 0 and drops the whitespace
after `: `, which still reduces file size by 50% or so.
Per feedback from the UCX community, we rarely do update
releases to anything but the current and one previous main
release stream.
Update comments in the UCX spack file to reflect this.
Signed-off-by: Howard Pritchard <howardp@lanl.gov>
