| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
* Ignore top-level module config; add auto-update
In Spack 0.17 we got module sets (modules:[name]:[prop]), and for
backwards compat modules:[prop] was short for modules:default:[prop].
But this makes it awkward to define default config for the "default"
module set.
Since 0.17 is branched off, we can now deprecate top-level module config
(that is, just ignore it with a warning).
This PR does that, and it implements `spack config update modules` to
make upgrading easy (we should have added that to 0.17 already...)
It also removes references to `dotkit` stuff which was already
deprecated in 0.13 and could have been removed in 0.14.
Prefix inspections are the only exception, since the top-level prefix inspections
used for `spack load` and `spack env activate`.
|
|
|
|
Co-authored-by: Mikael Simberg <mikael.simberg@iki.if>
|
|
Spack currently allows dependencies to be concretized for an
architecture incompatible with the root. This commit adds rules
to make this situation impossible by design.
|
|
|
|
|
|
|
|
* update metis: install more all files
* ok to be a package reviewer
Co-authored-by: Mathieu Courtois <mathieu.courtois@edf.fr>
|
|
|
|
|
|
|
|
|
|
|
|
* Extract the MetaPathFinder and Loaders for packages in their own classes
https://peps.python.org/pep-0451/
Currently, RepoPath and Repo implement the (deprecated) interface of
MetaPathFinder (find_module) and of Loader (load_module). This commit
extracts both of them and places the code in their own classes.
The MetaPathFinder interface is updated to contain both the deprecated
"find_module" (for Python 2.7 support) and the recommended "find_spec".
Update of the Loader interface is deferred at a subsequent commit.
* Move the lines to be prepended inside "RepoLoader"
Also adjust the naming of a few variables too
* Remove spack.util.imp, since code is only used in spack.repo
* Remove support from loading Python modules Python > 3 but < 3.5
* Remove `Repo._create_namespace`
This function was interacting badly with the MetaPathFinder
and causing issues with "normal" imports. Removing the
function allows to do things like:
```python
import spack.pkg.builtin.mpich
cls = spack.pkg.builtin.mpich.Mpich
```
* Remove code needed to trigger the Singleton evaluation
The finder is coded in a way to trigger the Singleton,
so we don't need external code now that we register it
at module level into `sys.meta_path`.
* Add unit tests
|
|
|
|
|
|
|
|
|
|
|
|
MPICH and OpenMPI share the same logic for these and these fixes have already been applied to MPICH.
See: https://github.com/spack/spack/pull/29284
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OpenMPI includes cuda_runtime.h, which errors with `#error --
unsupported GNU version! gcc versions later than 9 are not supported!`
By inheriting CudaPackage, the proper conflicts between `cuda` and
`gcc`/`clang` are added.
|
|
* Add checksum for fonttools@4.26.2
* Add python 3.6 dependency for py-fonttools@4.26.2 and update to 3.7 as of py-fonttools@4.28
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
Co-authored-by: Andrea Valenzuela <avalenzu@pccms161.dyndns.cern.ch>
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
|
|
* mesa, mesa18: Implement the swr variant consistently between mesa and mesa18
* mesa: Bump to 21.3.7
* mesa: Build release by default tie swr to release builds
* mesa, mesa18: re-enable the llvm variant by default
This reverts the change made in #29360
|
|
|
|
Some servers require `User-Agent` to be set, and otherwise error with
access denied. One such example is mpich.
To fix this, set `User-Agent: Spackbot/[version]` as a header.
Apparently by convention, it should include the word `bot`.
|
|
|
|
Show each `[src a] and [src b] both project to [dst]` on a separate
line.
|
|
|
|
|
|
Co-authored-by: sxs-bot <sxs-bot@users.noreply.github.com>
|
|
|
|
Update `warpx` & `py-warpx` to the latest release, `22.04`.
|
|
This was added in version 0.11.1.
|
|
|
|
|
|
Hipblas is now compulsory when building with rocm.
Co-authored-by: Harmen Stoppels <harmenstoppels@gmail.com>
|
|
|
|
Co-authored-by: Andrea Valenzuela <avalenzu@pccms161.dyndns.cern.ch>
|
|
|
