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.
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
