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.
Restores ability to build MSMPI from source.
* Modernizes the MSMPI package
* Strips out MSMPI build system that is long deprecated
* Adds patches to re-introduce missing functionality from said build system
* Adds builds + support for dependencies no longer fetched by build system
* cuda: Add 12.9 and new Blackwell targets
Including family-specific architecture features like sm_100f
* tau, caliper: Add cuda v12.9 conflict
Legacy nvtx was dropped.
* petsc: "libnvToolsExt.a" -> "libnvtx3interop.a" for cuda@12.9: and petsc@:3.23.1
* legion: Add upper bound to cuda version range
Avoid build failure due to CUDA driver API incompatibility.
See https://github.com/StanfordLegion/legion/issues/1864
---------
Co-authored-by: Satish Balay <balay@mcs.anl.gov>
When loading packages from a v1.0 repository, inject a line
from spack.build_systems._package_api import *
This allows removal of certain names in `spack.package` as part of api
v2 without breaking backward compatibility in Spack.
* update tfel package
* Update MGIS package
* add support for Version 5.0.1, 4.2.3, 4.1.4, 4.0.5, 3.4.8, 3.3.7, 3.2.12, 3.1.15 and 3.0.15
* add support for Versions 3.0.1 and 2.2.1
* Update crtm from jcsda/spack-stack-dev
* Update grads from jcsda/spack-stack-dev
* Update hdf from jcsda/spack-stack-dev
* Update ip from jcsda/spack-stack-dev
* Update met from jcsda/spack-stack-dev
* Update metplus from jcsda/spack-stack-dev
* Update py-kiwisolver from jcsda/spack-stack-dev
* Update py-pyogrio from jcsda/spack-stack-dev
* Update py-ruamel-yaml-clib from jcsda/spack-stack-dev
* Update wgrib2 from jcsda/spack-stack-dev
This PR modifies the parser, so that `%` is parsed as a `DEPENDENCY`, and all
node properties that follow are associated to the name after the `%`. e.g.,
in `foo %gcc +binutils` the `+binutils` refers to `gcc` and not to `foo`.
`%` is still parsed as a build-type dependency, at the moment.
Environments, config files and `package.py` files from before Spack v1.0 may have
spec strings with package variants, targets, etc. *after* a build dependency, and these
will need to be updated. You can use the `spack style --spec-strings` command to do this.
To see what strings will be parsed differently under Spack v1.0, run:
```
spack style --spec-strings FILES
```
where `FILES` is a list of filenames that may contain old specs. To update these spec
strings so that they parse correctly under both Spack 1.0 and Spack 0.x, you can run:
```
spack style --fix --spec-strings FILES
```
In the example above, `foo %gcc +binutils` would be rewritten as `foo +binutils %gcc`,
which parses the same in any Spack version.
In addition, this PR fixes several issues with `%` dependencies:
- [x] Ensure we can still constrain compilers on reuse
- [x] Ensure we can reuse a compiler by hash
- [x] Add tests
---------
Signed-off-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
