In particular, the 4.2.1 patches address a bug that prevents building
gcc with recent clang and glibc.
See details here: https://www.mpfr.org/mpfr-4.2.1/#fixed
* Add dependency on Python <= 3.11 for 8.0.4
The SafeConfigParser was removed in Python 3.12.
* Add version 11.5.3
* Add version 12.2.0
* Update order of version from newest to oldest
* Remove unneeded requirement on python@3.6
Since Spack only has Python 3.6 or newer anyway.
* Update license to BSD-3-Clause from version 12 onwards
* Set minimum Python version to 3.9 from version 12 onwards
* Add py-nvidia-ml-py dependency from version 12 onwards
* Update py-nvidia-ml-py package
- Change license to BSD-2-Clause
- Add many more versions
* Apply black formatting
* Add url_for_version helper function
Co-authored-by: Tamara Dahlgren <35777542+tldahlgren@users.noreply.github.com>
* Remove spaces on empty line
* Apply spack style
* Move depends_on directive
---------
Co-authored-by: Tamara Dahlgren <35777542+tldahlgren@users.noreply.github.com>
Allow other CI checks to continue even if the circular import check fails.
Circular imports are often indicative of code that needs to be restructured, but there
are still places where we need to add them. This allows CI to continue, so that if CI is
passing *except* for a problematic import, we can still force merge and accept a bit
of technical debt to admit a useful feature. Also, this allows people to keep working
while they fix their circular import issues, without being blind to CI results.
- [x] update ci workflow: import-check continue-on-error: true
* Updateing TAU recipe to add patch file for ROCM>6.2
* Create tau-rocm-disable-rocprofiler-default.patch
* Changing from version check to +rocm
* [@spackbot] updating style on behalf of jordialcaraz
---------
Co-authored-by: jordialcaraz <jordialcaraz@users.noreply.github.com>
Things done:
* Added variants for llvm plugin and gcc plugin
* Made binutils a proper variant
* Updated dependencies and their associated packages where applicable
* Modernization in progress: idiomatic use of `with_or_without` and `enable_or_disable` where it's trivial, transition towards `spec.satisfies(X)` rather than `X in spec`
TODO:
[x] Clean up RC entry/entries and add final tarball when available
[x] Be consistent about `spec.satisfies` everywhere: consistent enough for now
[x] Add `+mpi_f08` variant (is there a standard name for this?) (for 9.1, as commented)
---------
Co-authored-by: William Williams <william.williams@tu-dresden.de>
Co-authored-by: wrwilliams <wrwilliams@users.noreply.github.com>
Co-authored-by: Todd Gamblin <tgamblin@llnl.gov>
Now that build systems are finally part of repos,
we can remove the deprecated `intel` build system.
In the rare case some custom repo has recipes using
that build system, they can migrate to v2 and add
`intel` back to their repository.
Signed-off-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
Builders and package classes refer to packages from the builtin package
repo and are often modified together with packages. That means that
these classes should move into `spack_repo.builtin`.
* move `spack.build_systems` -> `spack_repo.builtin.build_systems`
* Remove the following re-exports from the `spack.package` module:
- `AspellDictPackage` - `LuaPackage`
- `AutotoolsPackage` - `MakefilePackage`
- `BundlePackage` - `MavenPackage`
- `CachedCMakePackage` - `MesonPackage`
- `cmake_cache_filepath` - `MSBuildPackage`
- `cmake_cache_option` - `NMakePackage`
- `cmake_cache_path` - `OctavePackage`
- `cmake_cache_string` - `PerlPackage`
- `CargoPackage` - `PythonExtension`
- `CMakePackage` - `PythonPackage`
- `generator` - `QMakePackage`
- `CompilerPackage` - `RacketPackage`
- `CudaPackage` - `RPackage`
- `Package` - `ROCmPackage`
- `GNUMirrorPackage` - `RubyPackage`
- `GoPackage` - `SConsPackage`
- `IntelPackage` - `SIPPackage`
- `IntelOneApiLibraryPackageWithSdk` - `SourceforgePackage`
- `IntelOneApiLibraryPackage` - `SourcewarePackage`
- `IntelOneApiStaticLibraryList` - `WafPackage`
- `IntelOneApiPackage` - `XorgPackage`
- `INTEL_MATH_LIBRARIES`
* update mock packages to repo v2.0 and add copies of packages/build
systems they use from builtin
* add missing imports to build systems in `package.py` from builtin
and test repos
* update various tests
This PR is breaking because of removal of various names from
`spack.package`, but breakage should be minimal thanks to #50496, which
ensures the above names are always imported in repo v1 packages.
Specifically this PR breaks imports like the following in `package.py` files:
```python
from spack.package import Package
```
but if your repo is v1.0 (see `spack repo list`) and has the following
much more common pattern:
```python
from spack.package import *
```
nothing should break.
