The argument is very likely a typo, and was meant to
be given to the fixture decorator. Since the value
being passed is the default, let's just remove it.
* metaeuk: new package
* sepp: new package
* busco: adding version 5.4.3
* busco: adding maintainers
* metauk: more accurate cmake dep
* sepp: adding missing dep and accurate python dep
* sepp: remove install_tree
* sepp: extend python
Ensure that build tools with module-level commands in spack use
the version built as part of their build graph if one exists.
This is now also required for mesa, scons, cmake and ctest, out
of graph versions of these tools in path will not be found unless
added as an external.
This bug appeared because a new version of rocprim needs cmake
3.16, while I have 3.14 in my path I had added an external for
cmake 3.20 to the dag, but 3.14 was still used to configure
rocprim causing it to fail. As far as I can tell, all the build
tools added in build_environment.py had this problem, despite the
fact that they should have been resolving these tools by name
with a path search and find the one in the dag that way. I'm
still investigating why the path searching and Executable logic
didn't do it, but this makes three of the build systems much more
explicit, and leaves only gmake and ninja as dependencies from
out in the system while ensuring the version in the dag is used
if there is one.
The additional sqlite version is to perturb the hash of python to
work around a relocation bug which will be fixed in a subsequent
PR.
The Python that comes with XCode command line tools is a bit weird.
This fixes two issues that were preventing it from bootstrapping:
- [x] CommandLineTools python does not come with a `python-config` executable. If you
don't have one of these, CMake's FindPython will, for some reason, assume that you
want Python 2, so you need to set `CLINGO_PYTHON_VERSION` to ensure that clingo
tells `find_package(Python <VERSION>)` the right thing.
- [x] We weren't setting `PYTHONHOME` correctly in Python's `package.py`. We were
setting it to the `prefix` from Python `sysconfig`, but `prefix` tells you where
the executable lives. CommandLineTools python reports its prefix as
/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8
but that doesn't exist. It looks like Apple builds the full python and just copies
pieces of it into command line tools. PYTHONHOME is supposed to tell you where the
default python library location is. So you have to look at the `base`, which
`sysconfig` reports as
/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8
On most systems this is probably the same as `prefix`, but not with
CommandLineTools, which has its system library in a different place.
The second change here was cherry-picked to 0d981a012d before merging and doesn't show
up here.
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
- [x] Rework `headers` to search a sequence of directories and to display all searched
locations on error, as opposed to handling each directory with a variable
- [x] Make `headers` and `libs` do the same type of search and raise the same sort of
errors.
Co-authored-by: Todd Gamblin <tgamblin@llnl.gov>
* [py-bitshuffle] New package
* [py-bitshuffle] compiling against spack hdf5
* [py-bitshuffle] flake8
* [py-bitshuffle] update import ine
* [@spackbot] updating style on behalf of qwertos
Co-authored-by: James A Zilberman <jazrc@rit.edu>
Co-authored-by: qwertos <qwertos@users.noreply.github.com>
We're seeing errors pop up with older versions of Kokkos and newer versions of
`oneapi`, specifically:
error: no member named 'ONEAPI' in namespace 'sycl'
This hapens because `sycl::ONEAPI` is `sycl::ext::oneapi` since oneapi `2022.0.0`.
`kokkos@3.6:` uses the new namespace. A conflict was present for this, but it was too
specific -- both to `dpcpp` and to the `2022.0.0` version.
- [x] Expand version ranges in `kokkos` conflict
- [x] Add conflict for `oneapi` in addition to `dpcpp`
* filesystem: use lstat in recursive mtime
When a `develop` path contains a dead symlink, the `os.stat` in the recursive `mtime` determination trips up over it.
Closes#32165.
`requirement_policy/3` is generated and may not be in Spack's inputs to Clingo.
Currently this is causing warnings like:
```
$ spack spec zlib
/global/u2/t/tgamblin/src/spack/lib/spack/spack/solver/concretize.lp:510:3-43: info: atom does not occur in any rule head:
requirement_policy(Package,X,"one_of")
/global/u2/t/tgamblin/src/spack/lib/spack/spack/solver/concretize.lp:517:3-43: info: atom does not occur in any rule head:
requirement_policy(Package,X,"one_of")
/global/u2/t/tgamblin/src/spack/lib/spack/spack/solver/concretize.lp:523:3-43: info: atom does not occur in any rule head:
requirement_policy(Package,X,"any_of")
/global/u2/t/tgamblin/src/spack/lib/spack/spack/solver/concretize.lp:534:3-43: info: atom does not occur in any rule head:
requirement_policy(Package,X,"any_of")
Input spec
--------------------------------
zlib
Concretized
--------------------------------
zlib@1.2.11%gcc@7.5.0+optimize+pic+shared arch=cray-sles15-haswell
```
- [x] Silence warning with `#defined requirement_policy/3`
Spack doesn't have an easy way to say something like "If I build
package X, then I *need* version Y":
* If you specify something on the command line, then you ensure
that the constraints are applied, but the package is always built
* Likewise if you `spack add X...`` to your environment, the
constraints are guaranteed to hold, but the environment always
builds the package
* You can add preferences to packages.yaml, but these are not
guaranteed to hold (Spack can choose other settings)
This commit adds a 'require' subsection to packages.yaml: the
specs added there are guaranteed to hold. The commit includes
documentation for the feature.
Co-authored-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
* celeritas: update checksum for git describe difference
Using `$Format:%h$` and the export-subst gitattribute property mean that
the release checksum can change post release...
```
$ diff -ru spack-stage-celeritas-0.1.0-hv7ewpjouekqws2y5iaql2cnp6tn76iz/ spack-stage-celeritas-0.1.0.wtf-ynyck3df2a7kkgkqrpwapgz3l2i62omz/
diff -ru spack-stage-celeritas-0.1.0-hv7ewpjouekqws2y5iaql2cnp6tn76iz/spack-src/cmake/CgvFindVersion.cmake spack-stage-celeritas-0.1.0.wtf-ynyck3df2a7kkgkqrpwapgz3l2i62omz/spack-src/cmake/CgvFindVersion.cmake
--- spack-stage-celeritas-0.1.0-hv7ewpjouekqws2y5iaql2cnp6tn76iz/spack-src/cmake/CgvFindVersion.cmake 2022-07-31 19:45:03.000000000 -0400
+++ spack-stage-celeritas-0.1.0.wtf-ynyck3df2a7kkgkqrpwapgz3l2i62omz/spack-src/cmake/CgvFindVersion.cmake 2022-07-31 19:45:03.000000000 -0400
@@ -75,7 +75,7 @@
# Get a possible Git version generated using git-archive (see the
# .gitattributes file)
- set(_ARCHIVE_TAG "HEAD -> master, tag: v0.1.0")
+ set(_ARCHIVE_TAG "tag: v0.1.0")
set(_ARCHIVE_HASH "04fe945d9")
set(_TAG_REGEX "v([0-9.]+)(-dev[0-9.]+)?")
Binary files spack-stage-celeritas-0.1.0-hv7ewpjouekqws2y5iaql2cnp6tn76iz/v0.1.0.tar.gz and spack-stage-celeritas-0.1.0.wtf-ynyck3df2a7kkgkqrpwapgz3l2i62omz/v0.1.0.tar.gz differ
```
* celeritas: Use exported and re-uploaded tar.gz for reproducibility
