| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Add conflicts to ginkgo and petsc to avoid build failures with cuda@12.4
Co-authored-by: pauleonix <pauleonix@users.noreply.github.com>
|
|
Add version 2024.01.1. Adjust the dependencies for develop that no
longer uses libmonitor.
|
|
* py-nilearn: add new version
* add maintainers and license
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Simon Potter <sp39@sanger.ac.uk>
|
|
|
|
|
|
It's now possible to add config on the command line with `spack -c <CONFIG_VARS> ...`, but the new `command_line` scope isn't reflected in the help output for `--scope`:
```bash
> spack help config
...
--scope {defaults,system,site,user}[/PLATFORM] or env:ENVIRONMENT
configuration scope to read/modify
...
```
|
|
|
|
|
|
This PR adds:
- A new runtime for `%oneapi` compilers, called `intel-oneapi-runtime`
- Information to both `gcc-runtime` and `intel-oneapi-runtime`, to ensure
that we don't mix compilers using different soname for either `libgfortran`
or `libifcore`
To do so, the following internal mechanisms have been implemented:
- Possibility to inject virtual dependencies from the `runtime_constraints`
callback on packages
Information has been added to `gcc-runtime` to provide the correct soname
under different conditions on its `%gcc`.
Rules injected into the solver looks like:
```prolog
% Add a dependency on 'gfortran@5' for nodes compiled with gcc@=13.2.0 and using the 'fortran' language
attr("dependency_holds", node(ID, Package), "gfortran", "link") :-
attr("node", node(ID, Package)),
attr("node_compiler", node(ID, Package), "gcc"),
attr("node_compiler_version", node(ID, Package), "gcc", "13.2.0"),
not external(node(ID, Package)),
not runtime(Package),
attr("language", node(ID, Package), "fortran").
attr("virtual_node", node(RuntimeID, "gfortran")) :-
attr("depends_on", node(ID, Package), ProviderNode, "link"),
provider(ProviderNode, node(RuntimeID, "gfortran")),
attr("node", node(ID, Package)),
attr("node_compiler", node(ID, Package), "gcc"),
attr("node_compiler_version", node(ID, Package), "gcc", "13.2.0"),
not external(node(ID, Package)),
not runtime(Package),
attr("language", node(ID, Package), "fortran").
attr("node_version_satisfies", node(RuntimeID, "gfortran"), "5") :-
attr("depends_on", node(ID, Package), ProviderNode, "link"),
provider(ProviderNode, node(RuntimeID, "gfortran")),
attr("node", node(ID, Package)),
attr("node_compiler", node(ID, Package), "gcc"),
attr("node_compiler_version", node(ID, Package), "gcc", "13.2.0"),
not external(node(ID, Package)),
not runtime(Package),
attr("language", node(ID, Package), "fortran").
```
|
|
Co-authored-by: loikki <loic.hausammann@id.ethz.ch>
|
|
|
|
Co-authored-by: openCARP consortium <info@opencarp.org>
|
|
* py-kaledio: Fix completely borked package.py
* Readd stuff I forgot to add
* And one last missing thing
* Remove python restriction
* [@spackbot] updating style on behalf of Pandapip1
* Add MacOS build
* Fix checksum
* Handle all supported OSes
* Split imports
* Remove extra version stuff
|
|
Co-authored-by: Gava, Francesco <francesco.gava@mclaren.com>
|
|
|
|
Co-authored-by: sbulut <sbulut@3vgeomatics.com>
Co-authored-by: Bernhard Kaindl <bernhardkaindl7@gmail.com>
|
|
|
|
py-packaging (#43306)
|
|
|
|
Co-authored-by: jmcarcell <jmcarcell@users.noreply.github.com>
|
|
|
|
Signed-off-by: Howard Pritchard <hppritcha@gmail.com>
|
|
|
|
|
|
0.23.0 (#43249)
|
|
|
|
* expand fftw patch appliance range to include 7.2.2
* fix formatting bug
|
|
|
|
|
|
|
|
|
|
The default url couldn't be the one with v0.0.0-aws since spack was
replacing v0.0.0-aws with v<version_number> for example, deleting the
-aws suffix. I used the url_for_version method to specify this suffix.
|
|
|
|
|
|
This adds support for prereleases. Alpha, beta and release candidate
suffixes are ordered in the intuitive way:
```
1.2.0-alpha < 1.2.0-alpha.1 < 1.2.0-beta.2 < 1.2.0-rc.3 < 1.2.0 < 1.2.0-xyz
```
Alpha, beta and rc prereleases are defined as follows: split the version
string into components like before (on delimiters and string boundaries).
If there's a string component `alpha`, `beta` or `rc` followed by an optional
numeric component at the end, then the version is prerelease.
So `1.2.0-alpha.1 == 1.2.0alpha1 == 1.2.0.alpha1` are all the same, as usual.
The strings `alpha`, `beta` and `rc` are chosen because they match semver,
they are sufficiently long to be unambiguous, and and all contain at least
one non-hex character so distinguish them from shasum/digest type suffixes.
The comparison key is now stored as `(release_tuple, prerelease_tuple)`, so in
the above example:
```
((1,2,0),(ALPHA,)) < ((1,2,0),(ALPHA,1)) < ((1,2,0),(BETA,2)) < ((1,2,0),(RC,3)) < ((1,2,0),(FINAL,)) < ((1,2,0,"xyz"), (FINAL,))
```
The version ranges `@1.2.0:` and `@:1.1` do *not* include prereleases of
`1.2.0`.
So for packaging, if the `1.2.0alpha` and `1.2.0` versions have the same constraints on
dependencies, it's best to write
```python
depends_on("x@1:", when="@1.2.0alpha:")
```
However, `@1.2:` does include `1.2.0alpha`. This is because Spack considers
`1.2 < 1.2.0` as distinct versions, with `1.2 < 1.2.0alpha < 1.2.0` as a consequence.
Alternatively, the above `depends_on` statement can thus be written
```python
depends_on("x@1:", when="@1.2:")
```
which can be useful too. A short-hand to include prereleases, but you
can still be explicit to exclude the prerelease by specifying the patch version
number.
### Concretization
Concretization uses a different version order than `<`. Prereleases are ordered
between final releases and develop versions. That way, users should not
have to set `preferred=True` on every final release if they add just one
prerelease to a package. The concretizer is unlikely to pick a prerelease when
final releases are possible.
### Limitations
1. You can't express a range that includes all alpha release but excludes all beta
releases. Only alternative is good old repeated nines: `@:1.2.0alpha99`.
2. The Python ecosystem defaults to `a`, `b`, `rc` strings, so translation of Python versions to
Spack versions requires expansion to `alpha`, `beta`, `rc`. It's mildly annoying, because
this means we may need to compute URLs differently (not done in this commit).
### Hash
Care is taken not to break hashes of versions that do not have a prerelease
suffix.
|
|
Generate CI scripts as powershell on Windows. This is intended to
output exactly the same bash scripts as before on Linux.
Co-authored-by: Ryan Krattiger <ryan.krattiger@kitware.com>
|
|
|
|
Signed-off-by: Bernhard Kaindl <bernhardkaindl7@gmail.com>
|
|
* Make sure APEX_WITH_KOKKOS CMake option is set in apex
* Add conflict for apex with ~kokkos
|
|
* elpa streams
* [@spackbot] updating style on behalf of RMeli
* Apply suggestions from @albestro
* Update var/spack/repos/builtin/packages/elpa/package.py
Co-authored-by: Mikael Simberg <mikael.simberg@iki.fi>
---------
Co-authored-by: RMeli <RMeli@users.noreply.github.com>
Co-authored-by: Mikael Simberg <mikael.simberg@iki.fi>
|
|
As the cmake build is triggered by scikit build, the usual spack option
for enabling tests had no effect and the heavy test suite ran all the time.
Used https://github.com/scikit-build/cmake-python-distributions/issues/172#issuecomment-890322263
to implement how to pass options to the actual `cmake` build.
I also excluded some tests that failed for me on alma9 (gcc 11.4.1),
so the rest of the test suite can be run.
|
|
|
