summaryrefslogtreecommitdiff
path: root/var
AgeCommit message (Collapse)AuthorFilesLines
2023-05-05Improve version, version range, and version list syntax and behavior (#36273)Harmen Stoppels22-35/+35
## Version types, parsing and printing - The version classes have changed: `VersionBase` is removed, there is now a `ConcreteVersion` base class. `StandardVersion` and `GitVersion` both inherit from this. - The public api (`Version`, `VersionRange`, `ver`) has changed a bit: 1. `Version` produces either `StandardVersion` or `GitVersion` instances. 2. `VersionRange` produces a `ClosedOpenRange`, but this shouldn't affect the user. 3. `ver` produces any of `VersionList`, `ClosedOpenRange`, `StandardVersion` or `GitVersion`. - No unexpected type promotion, so that the following is no longer an identity: `Version(x) != VersionRange(x, x)`. - `VersionList.concrete` now returns a version if it contains only a single element subtyping `ConcreteVersion` (i.e. `StandardVersion(...)` or `GitVersion(...)`) - In version lists, the parser turns `@x` into `VersionRange(x, x)` instead of `Version(x)`. - The above also means that `ver("x")` produces a range, whereas `ver("=x")` produces a `StandardVersion`. The `=` is part of _VersionList_ syntax. - `VersionList.__str__` now outputs `=x.y.z` for specific version entries, and `x.y.z` as a short-hand for ranges `x.y.z:x.y.z`. - `Spec.format` no longer aliases `{version}` to `{versions}`, but pulls the concrete version out of the list and prints that -- except when the list is is not concrete, then is falls back to `{versions}` to avoid a pedantic error. For projections of concrete specs, `{version}` should be used to render `1.2.3` instead of `=1.2.3` (which you would get with `{versions}`). The default `Spec` format string used in `Spec.__str__` now uses `{versions}` so that `str(Spec(string)) == string` holds. ## Changes to `GitVersion` - `GitVersion` is a small wrapper around `StandardVersion` which enriches it with a git ref. It no longer inherits from it. - `GitVersion` _always_ needs to be able to look up an associated Spack version if it was not assigned (yet). It throws a `VersionLookupError` whenever `ref_version` is accessed but it has no means to look up the ref; in the past Spack would not error and use the commit sha as a literal version, which was incorrect. - `GitVersion` is never equal to `StandardVersion`, nor is satisfied by it. This is such that we don't lose transitivity. This fixes the following bug on `develop` where `git_version_a == standard_version == git_version_b` does not imply `git_version_a == git_version_b`. It also ensures equality always implies equal hash, which is also currently broken on develop; inclusion tests of a set of versions + git versions would behave differently from inclusion tests of a list of the same objects. - The above means `ver("ref=1.2.3) != ver("=1.2.3")` could break packages that branch on specific versions, but that was brittle already, since the same happens with externals: `pkg@1.2.3-external` suffixes wouldn't be exactly equal either. Instead, those checks should be `x.satisfies("@1.2.3")` which works both for git versions and custom version suffixes. - `GitVersion` from commit will now print as `<hash>=<version>` once the git ref is resolved to a spack version. This is for reliability -- version is frozen when added to the database and queried later. It also improves performance since there is no need to clone all repos of all git versions after `spack clean -m` is run and something queries the database, triggering version comparison, such as potentially reuse concretization. - The "empty VerstionStrComponent trick" for `GitVerison` is dropped since it wasn't representable as a version string (by design). Instead, it's replaced by `git`, so you get `1.2.3.git.4` (which reads 4 commits after a tag 1.2.3). This means that there's an edge case for version schemes `1.1.1`, `1.1.1a`, since the generated git version `1.1.1.git.1` (1 commit after `1.1.1`) compares larger than `1.1.1a`, since `a < git` are compared as strings. This is currently a wont-fix edge case, but if really required, could be fixed by special casing the `git` string. - Saved, concrete specs (database, lock file, ...) that only had a git sha as their version, but have no means to look the effective Spack version anymore, will now see their version mapped to `hash=develop`. Previously these specs would always have their sha literally interpreted as a version string (even when it _could_ be looked up). This only applies to databases, lock files and spec.json files created before Spack 0.20; after this PR, we always have a Spack version associated to the relevant GitVersion). - Fixes a bug where previously `to_dict` / `from_dict` (de)serialization would not reattach the repo to the GitVersion, causing the git hash to be used as a literal (bogus) version instead of the resolved version. This was in particularly breaking version comparison in the build process on macOS/Windows. ## Installing or matching specific versions - In the past, `spack install pkg@3.2` would install `pkg@=3.2` if it was a known specific version defined in the package, even when newer patch releases `3.2.1`, `3.2.2`, `...` were available. This behavior was only there because there was no syntax to distinguish between `3.2` and `3.2.1`. Since there is syntax for this now through `pkg@=3.2`, the old exact matching behavior is removed. This means that `spack install pkg@3.2` constrains the `pkg` version to the range `3.2`, and `spack install pkg@=3.2` constrains it to the specific version `3.2`. - Also in directives such as `depends_on("pkg@2.3")` and their when conditions `conflicts("...", when="@2.3")` ranges are ranges, and specific version matches require `@=2.3.`. - No matching version: in the case `pkg@3.2` matches nothing, concretization errors. However, if you run `spack install pkg@=3.2` and this version doesn't exist, Spack will define it; this allows you to install non-registered versions. - For consistency, you can now do `%gcc@10` and let it match a configured `10.x.y` compiler. It errors when there is no matching compiler. In the past it was interpreted like a specific `gcc@=10` version, which would get bootstrapped. - When compiler _bootstrapping_ is enabled, `%gcc@=10.2.0` can be used to bootstrap a specific compiler version. ## Other changes - Externals, compilers, and develop spec definitions are backwards compatible. They are typically defined as `pkg@3.2.1` even though they should be saying `pkg@=3.2.1`. Spack now transforms `pkg@3` into `pkg@=3` in those cases. - Finally, fix strictness of `version(...)` directive/declaration. It just does a simple type check, and now requires strings/integers. Floats are not allowed because they are ambiguous `str(3.10) == "3.1"`.
2023-05-05apr: add v1.7.4 (#37445)Alec Scott1-0/+1
2023-05-05fms: add v2023.01 (#37450)Alec Scott1-0/+1
2023-05-05py-palettable: add 3.3.3 (#37443)Manuela Kuhn1-0/+1
2023-05-05hdf5: Add conflict for older cmake versions. (#37463)Mittagskogel1-0/+4
See HDFGroup/hdf5 issue 2906
2023-05-05phast: add v1.6 (#37455)Alec Scott1-0/+1
2023-05-05mmg: add v5.7.1 (#37453)Alec Scott1-0/+1
2023-05-05octave: add v8.2.0 (#37454)Alec Scott1-0/+1
2023-05-05logrotate: add v3.21.0 (#37452)Alec Scott1-0/+1
2023-05-05extrae: add v4.0.4 (#37449)Alec Scott1-0/+1
2023-05-05cli11: add v2.3.2 (#37447)Alec Scott1-0/+1
2023-05-05Adding ncbi-vdb 3.0.2 (#37435)snehring2-0/+2
* ncbi-vdb: adding version 3.0.2 * sra-tools: adding version restriction for newer versions
2023-05-05biobloom: add v2.3.5 (#37446)Alec Scott1-0/+1
2023-05-05editline: add v1.17.1 (#37448)Alec Scott1-0/+1
2023-05-05binutils: enable debug section compression with zlib by default (#37359)Harmen Stoppels1-0/+16
2023-05-05elfutils: unconditionally depend on zstd (#37368)Harmen Stoppels2-25/+13
2023-05-05meson: change default build type to "release" (#37436)Michael Kuhn1-8/+0
The same was done for CMake in #36679.
2023-05-05mpich: avoid '-fallow-argument-mismatch' in the compiler wrappers (#33323)Sergey Kosukhin1-12/+14
2023-05-05cleaveland4: add v4.5 (#37319)Alec Scott1-0/+1
2023-05-05Revert "lua: add v5.4.5 (#37334)" (#37431)Alec Scott1-1/+0
This reverts commit 59e2ef6ad64b12fd7f168308f3ac87b7472d2994.
2023-05-04intel-oneapi-mkl: include mpi libs when using +cluster (#37386)Robert Cohn1-1/+4
2023-05-04iperf2: Add new versions 2.1.{7,8,9} (#37408)Jack Morrison1-0/+3
2023-05-04py-amici, py-python-libsbml: new packages (#35532)Erik Heeren2-0/+68
* py-amici, py-python-libsbml: new packages * Apply suggestions from code review Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com> * Swig and cmake are build-only dependencies * cmake as a run dependency after all * py-amici: default boost and hdf5 variants to True --------- Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
2023-05-04perl: fix jobserver job issue (#37428)Harmen Stoppels1-0/+6
When building perl with posix jobserver, it seems to eat jobs, which reduces parallelism to 1 in many cases, and is rather annoying. This is solved in GNU Make 4.4 (fifo is more stable than file descriptors), but that version is typically not available. So, fix this issue by simply unsetting MAKEFLAGS for the duration of ./Configure. That's enough, and the build phase runs perfectly in parallel again.
2023-05-04cmake build system: change default build type to `Release` (#36679)Massimiliano Culpo25-174/+0
This switches the default Make build type to `build_type=Release`. This offers: - higher optimization level, including loop vectorization on older GCC - adds NDEBUG define, which disables assertions, which could cause speedups if assertions are in loops etc - no `-g` means smaller install size Downsides are: - worse backtraces (though this does NOT strip symbols) - perf reports may be useless - no function arguments / local variables in debugger (could be of course) - no file path / line numbers in debugger The downsides can be mitigated by overriding to `build_type=RelWithDebInfo` in `packages.yaml`, if needed. The upside is that builds will be MUCH smaller (and faster) with this change. --------- Co-authored-by: Gregory Becker <becker33@llnl.gov>
2023-05-04Add pika 0.15.0 (#37403)Mikael Simberg1-0/+1
2023-05-04Add patches for generic context coroutine stack allocation in pika on macos ↵Mikael Simberg6-0/+73
(#37288)
2023-05-04cabana: Add optional silo build (#37393)Sam Reeve1-1/+3
2023-05-03py-lightly: add v1.4.4 (#37406)Adam J. Stewart1-0/+1
2023-05-03libjwt: add v1.15.2 (#37333)Alec Scott1-0/+1
2023-05-03mii: add v1.1.2 (#37335)Alec Scott1-0/+1
2023-05-03texinfo: add v7.0.3 (#37348)Alec Scott1-0/+1
2023-05-03py-mne: add 1.3.1 (#37399)Manuela Kuhn1-2/+1
2023-05-03py-neurora: add 1.1.6.9 (#37398)Manuela Kuhn1-0/+1
2023-05-03py-neurokit2: add 0.2.4 (#37396)Manuela Kuhn1-0/+1
2023-05-03py-bidskit: add 2023.2.16 (#37395)Manuela Kuhn1-0/+1
2023-05-03py-nilearn: add 0.10.1 (#37394)Manuela Kuhn1-4/+6
2023-05-03perl-module-install: add v1.21 (#37341)Alec Scott1-0/+1
2023-05-03Intel MPI Benchmarks 'IMB-P2P' is available for versions newer than 2018. ↵Jack Morrison1-1/+1
(#37360)
2023-05-03intel-tbb: Add versions 2021.8.0 and 2021.9.0 (#37391)Tim Haines1-0/+2
2023-05-02libintl, iconv, gettext: account for libc provider and externals (#35450)Chris Green39-127/+243
* libiconv can be provided by libc, so update packages which depend on libiconv to require the iconv virtual instead * Many packages need special consideration when locating iconv depending on whether it is provided by libc (no prefix provided) or the libiconv package (in that case we want to provide a prefix) * It was also noticed that when an iconv external was provided, that there was interference with linking (this should generally be handled by Spack's compiler wrappers and bears further investigation) * Like iconv, libintl can be provided by libc or another package, namely gettext. It is not converted to a provider like libiconv because it provides additional routines. The logic is similar to that of iconv but instead of checking the provider, we check whether the gettext installation includes libintl.
2023-05-02Guard use of OpenMP in rocblas test (#36673)renjithravindrankannath2-1/+415
* Provide openmp from rocm-open-extras for roblas test * Addressing the prechecks/audit/package-audits check * Correcting style check errors. * rocm-openmp-extras path veriable restricting for test * Correcting the env variable to run_tests * Guard use of OpenMP to make it optional in rocblas test * Removing unused patch
2023-05-02trilinos: add version 14.0.0 (#37387)Zack Galbreath1-0/+1
2023-05-02GitHub Actions: do not install six in CI (#37361)Massimiliano Culpo5-20/+10
* GitHub Actions: do not install six in CI * Remove workflow code that was commented out * Remove any use of "six" from packages
2023-05-02hip: Patch to handle file reorg changes for the tests (#36993)renjithravindrankannath2-0/+142
* Patch to handle file reorg changes for the tests * Correcting patch file name * Limiting hipify-clang path to 5.4 and later * Set hipify-clang path env in CMake
2023-05-02gromacs: add 2023.1 version (#37371)Daniel Ahlin1-0/+1
2023-05-02muparser: add v2.3.4 (#37298)Alec Scott1-0/+1
2023-05-02globalarrays: add v5.8.2 (#37325)Alec Scott1-0/+1
2023-05-02spot: add v2.11.5 (#37299)Alec Scott1-0/+1
2023-05-02osi: add v0.108.8 (#37340)Alec Scott1-0/+1