summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-05-10unifdef: add v2.12 (#37456)Alec Scott1-0/+1
2023-05-10conmon: add v2.1.7 (#37320)Alec Scott1-0/+1
2023-05-10runc: add v1.1.6 (#37308)Alec Scott1-0/+1
2023-05-10py-datalad: add 0.18.3 (#37411)Manuela Kuhn1-15/+31
* py-datalad: add 0.18.3 * [@spackbot] updating style on behalf of manuelakuhn * Remove metadata variant * Fix dependencies * Remove redundant version restriction
2023-05-09r-knitr: add v1.42 (#37203)Alec Scott1-4/+7
2023-05-09ssht: add v1.5.2 (#37542)Alec Scott1-0/+1
2023-05-09py-loguru: add v0.2.5, v0.3.0 (#37574)eugeneswalker1-0/+2
* py-loguru: add v0.2.5 * py-loguru: add v0.3.0
2023-05-09CI: Backwards compatibility requires script override behavior (#37015)kwryankrattiger1-4/+23
2023-05-09memkind: parallel = false (#37566)eugeneswalker1-0/+3
2023-05-09z-checker: add v0.9.0 (#37534)Alec Scott1-0/+1
2023-05-09hip: get_paths for hipify-clang (#37559)eugeneswalker1-1/+7
* hip: get_paths for hipify-clang * fix: need to actually use get_paths now to get hipify-clang path * set hipify-clang path differentluy for external vs spack-installed case * [@spackbot] updating style on behalf of eugeneswalker
2023-05-09Use single quotes to inline manifest in Dockerfiles (#37571)Massimiliano Culpo2-3/+19
fixes #22341 Using double quotes creates issues with shell variable substitutions, in particular when the manifest has "definitions:" in it. Use single quotes instead.
2023-05-09spack view copy: relocate symlinks (#32306)Harmen Stoppels1-33/+33
2023-05-09gh: add conflict for v2.28.0 and macos (#37563)Alec Scott1-0/+2
2023-05-08breseq: add v0.38.1 (#37535)Alec Scott1-0/+1
2023-05-08exiv2: add v0.27.6 (#37536)Alec Scott1-0/+1
2023-05-08hazelcast: add v5.2.3 (#37537)Alec Scott1-0/+1
2023-05-08libjpeg-turbo: add v2.1.5 (#37539)Alec Scott1-0/+1
2023-05-08mlst: add v2.23.0 (#37540)Alec Scott1-0/+1
2023-05-08scitokens-cpp: add v1.0.1 (#37541)Alec Scott1-0/+1
2023-05-08delta: add v2.3.0 (#37545)Alec Scott1-0/+1
2023-05-08fd-find: add v8.7.0 (#37547)Alec Scott0-0/+0
2023-05-08druid: add v1.2.8 (#37546)Alec Scott1-0/+1
2023-05-08fd-find: add v8.7.0 (#37547)Alec Scott1-0/+1
2023-05-08hpcviewer: add version 2023.04 (#37556)Mark W. Krentel1-0/+5
2023-05-08use latest trilinos for +cuda variants (#37164)eugeneswalker2-4/+4
2023-05-08new package: psalg (#37357)eugeneswalker1-0/+23
* new package: psalg * use new maintainer syntax Co-authored-by: Tamara Dahlgren <35777542+tldahlgren@users.noreply.github.com> --------- Co-authored-by: Tamara Dahlgren <35777542+tldahlgren@users.noreply.github.com>
2023-05-08Add a "requires" directive, extend functionality of package requirements ↵Massimiliano Culpo14-136/+628
(#36286) Add a "require" directive to packages, which functions exactly like requirements specified in packages.yaml (uses the same fact-generation logic); update both to allow making the requirement conditional. * Packages may now use "require" to add constraints. This can be useful for something like "require(%gcc)" (where before we had to add a conflict for every compiler except gcc). * Requirements (in packages.yaml or in a "require" directive) can be conditional on a spec, e.g. "require(%gcc, when=@1.0.0)" (version 1.0.0 can only build with gcc). * Requirements may include a message which clarifies why they are needed. The concretizer assigns a high priority to errors which generate these messages (in particular over errors for unsatisfied requirements that do not produce messages, but also over a number of more-generic errors).
2023-05-08caliper +rocm: use hipcc for CMAKE_CXX_COMPILER (#35219)eugeneswalker1-0/+1
2023-05-08libmonitor: add version 2023.03.15 (#37434)Mark W. Krentel1-0/+1
2023-05-08Fix pixman macOS build and add missing build deps (#36982)Seth R. Johnson1-1/+9
2023-05-08trinity: adding version 2.15.1 (#37076)snehring2-0/+18
2023-05-08Add HPX 1.9.0 (#37426)Mikael Simberg1-1/+12
2023-05-07pkgconf: add v1.9.4 (#36437)Alec Scott1-0/+1
2023-05-07caliper +rocm: patch missing libunwind include dir (#37461)eugeneswalker2-0/+15
* patch missing libunwind include dir * caliper +libunwind +sampler: patch libunwind include dir
2023-05-07petsc@3.19.1 +rocm: conflicts with rocprim@5.3.0 (#37474)eugeneswalker1-0/+3
* petsc@3.19.1 +rocm: conflicts with rocprim@5.3.0 * conflict with rocprim@5.3.0:5.3.2 when +rocm
2023-05-07libtiff: add v4.5.0 (#37523)Alec Scott1-0/+1
2023-05-07gitlab ci: bump tutorial image (#37544)Harmen Stoppels2-3/+3
2023-05-07libblastrampoline: add v5.8.0 (#37538)Alec Scott1-0/+1
2023-05-05libpcap: add v1.10.4 (#37451)Alec Scott1-0/+1
2023-05-05Packaging Guide: build-time test updates: option and test logs (#37093)Tamara Dahlgren1-5/+59
* Packaging Guide: build-time test updates: option and test logs * Fix a couple of typos
2023-05-05[elfutils] iconv is required (see ./configure --help) (#37464)Chris Green1-0/+1
2023-05-05Improve version, version range, and version list syntax and behavior (#36273)Harmen Stoppels91-1847/+2036
## 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