Releases: spack/spack
v0.22.0 (2024-05-12)
v0.22.0
is a major feature release.
Features in this release
-
Compiler dependencies
We are in the process of making compilers proper dependencies in Spack, and a number
of changes inv0.22
support that effort. You may notice nodes in your dependency
graphs for compiler runtime libraries likegcc-runtime
orlibgfortran
, and you
may notice that Spack graphs now includelibc
. We've also begun moving compiler
configuration fromcompilers.yaml
topackages.yaml
to make it consistent with
other externals. We are trying to do this with the least disruption possible, so
your existingcompilers.yaml
files should still work. We expect to be done with
this transition by thev0.23
release in November.-
#41104: Packages compiled with
%gcc
on Linux, macOS and FreeBSD now depend on a
new packagegcc-runtime
, which contains a copy of the shared compiler runtime
libraries. This enables gcc runtime libraries to be installed and relocated when
using a build cache. When building minimal Spack-generated container images it is
no longer necessary to install libgfortran, libgomp etc. using the system package
manager. -
#42062: Packages compiled with
%oneapi
now depend on a new package
intel-oneapi-runtime
. This is similar togcc-runtime
, and the runtimes can
provide virtuals and compilers can inject dependencies on virtuals into compiled
packages. This allows us to model library soname compatibility and allows
compilers like%oneapi
to provide virtuals likesycl
(which can also be
provided by standalone libraries). Note that until we have an agreement in place
with intel, Intel packages are markedredistribute(source=False, binary=False)
and must be downloaded outside of Spack. -
#43272: changes to the optimization criteria of the solver improve the hit-rate of
buildcaches by a fair amount. The solver more relaxed compatibility rules and will
not try to strictly match compilers or targets of reused specs. Users can still
enforce the previous strict behavior withrequire:
sections inpackages.yaml
.
Note that to enforce correct linking, Spack will not reuse old%gcc
and
%oneapi
specs that do not have the runtime libraries as a dependency. -
#43539: Spack will reuse specs built with compilers that are not explicitly
configured incompilers.yaml
. Because we can now keep runtime libraries in build
cache, we do not require you to also have a local configured compiler to use the
runtime libraries. This improves reuse in buildcaches and avoids conflicts with OS
updates that happen underneath Spack. -
#43190: binary compatibility on
linux
is now based on thelibc
version,
instead of on theos
tag. Spack builds now detect the hostlibc
(glibc
or
musl
) and add it as an implicit external node in the dependency graph. Binaries
with alibc
with the same name and a version less than or equal to that of the
detectedlibc
can be reused. This is only onlinux
, notmacos
orWindows
. -
#43464: each package that can provide a compiler is now detectable using
spack external find
. External packages defining compiler paths are effectively used as
compilers, andspack external find -t compiler
can be used as a substitute for
spack compiler find
. More details on this transition are in
the docs
-
-
Improved
spack find
UI for EnvironmentsIf you're working in an enviroment, you likely care about:
- What are the roots
- Which ones are installed / not installed
- What's been added that still needs to be concretized
We've tweaked
spack find
in environments to show this information much more
clearly. Installation status is shown next to each root, so you can see what is
installed. Roots are also shown in bold in the list of installed packages. There is
also a new option forspack find -r
/--only-roots
that will only show env
roots, if you don't want to look at all the installed specs.More details in #42334.
-
Improved command-line string quoting
We are making some breaking changes to how Spack parses specs on the CLI in order to
respect shell quoting instead of trying to fight it. If you (sadly) had to write
something like this on the command line:spack install zlib cflags=\"-O2 -g\"
That will now result in an error, but you can now write what you probably expected
to work in the first place:spack install zlib cflags="-O2 -g"
Quoted can also now include special characters, so you can supply flags like:
spack intall zlib ldflags='-Wl,-rpath=$ORIGIN/_libs'
To reduce ambiguity in parsing, we now require that you not put spaces around
=
and==
when for flags or variants. This would not have broken before but will now
result in an error:spack install zlib cflags = "-O2 -g"
More details and discussion in #30634.
-
Revert default
spack install
behavior to--reuse
We changed the default concretizer behavior from
--reuse
to--reuse-deps
in
#30990 (inv0.20
), which meant that everyspack install
invocation would
attempt to build a new version of the requested package / any environment roots.
While this is a common ask for upgrading and for developer workflows, we don't
think it should be the default for a package manager.We are going to try to stick to this policy:
- Prioritize reuse and build as little as possible by default.
- Only upgrade or install duplicates if they are explicitly asked for, or if there
is a known security issue that necessitates an upgrade.
With the install command you now have three options:
--reuse
(default): reuse as many existing installations as possible.--reuse-deps
/--fresh-roots
: upgrade (freshen) roots but reuse dependencies if possible.--fresh
: install fresh versions of requested packages (roots) and their dependencies.
We've also introduced
--fresh-roots
as an alias for--reuse-deps
to make it more clear
that it may give you fresh versions. More details in #41302 and #43988. -
More control over reused specs
You can now control which packages to reuse and how. There is a new
concretizer:reuse
config option, which accepts the following properties:roots
:true
to reuse roots,false
to reuse just dependenciesexclude
: list of constraints used to select which specs not to reuseinclude
: list of constraints used to select which specs to reusefrom
: list of sources for reused specs (some combination oflocal
,
buildcache
, orexternal
)
For example, to reuse only specs compiled with GCC, you could write:
concretizer: reuse: roots: true include: - "%gcc"
Or, if
openmpi
must be used from externals, and it must be the only external used:concretizer: reuse: roots: true from: - type: local exclude: ["openmpi"] - type: buildcache exclude: ["openmpi"] - type: external include: ["openmpi"]
-
New
redistribute()
directiveSome packages can't be redistributed in source or binary form. We need an explicit
way to say that in a package.Now there is a
redistribute()
directive so that package authors can write:class MyPackage(Package): redistribute(source=False, binary=False)
Like other directives, this works with
when=
:class MyPackage(Package): # 12.0 and higher are proprietary redistribute(source=False, binary=False, when="@12.0:") # can't redistribute when we depend on some proprietary dependency redistribute(source=False, binary=False, when="^proprietary-dependency")
More in #20185.
-
New
conflict:
andprefer:
syntax for package preferencesPreviously, you could express conflicts and preferences in
packages.yaml
through
some contortions withrequire:
:packages: zlib-ng: require: - one_of: ["%clang", "@:"] # conflict on %clang - any_of: ["+shared", "@:"] # strong preference for +shared
You can now use
require:
andprefer:
for a much more readable configuration:packages: zlib-ng: conflict: - "%clang" prefer: - "+shared"
See the documentation
and #41832 for more details. -
include_concrete
in environmentsYou may want to build on the concrete contents of another environment without
changing that environment. You can now include the concrete specs from another
environment'sspack.lock
withinclude_concrete
:spack: specs: [] concretizer: unify: true include_concrete: - /path/to/environment1 - /path/to/environment2
Now, when this environment is concretized, it will bring in the already concrete
specs fromenvironment1
andenvironment2
, and build on top of them without
changing them. This is useful if you have phased de...
v0.21.2 (2024-03-01)
Bugfixes
- Containerize: accommodate nested or pre-existing spack-env paths (#41558)
- Fix setup-env script, when going back and forth between instances (#40924)
- Fix using fully-qualified namespaces from root specs (#41957)
- Fix a bug when a required provider is requested for multiple virtuals (#42088)
- OCI buildcaches:
- Fix using sticky variants in externals (#42253)
- Fix a rare issue with conditional requirements and multi-valued variants (#42566)
Package updates
v0.21.1 (2024-01-11)
New features
- Add support for reading buildcaches created by Spack v0.22 (#41773)
Bugfixes
- spack graph: fix coloring with environments (#41240)
- spack info: sort variants in --variants-by-name (#41389)
- Spec.format: error on old style format strings (#41934)
- ASP-based solver:
- Improve the error message for deprecated preferences (#41075)
- Fix MSVC preview version breaking clingo build on Windows (#41185)
- Fix multi-word aliases (#41126)
- Add a warning for unconfigured compiler (#41213)
- environment: fix an issue with deconcretization/reconcretization of specs (#41294)
- buildcache: don't error if a patch is missing, when installing from binaries (#41986)
- Multiple improvements to unit-tests (#41215,#41369,#41495,#41359,#41361,#41345,#41342,#41308,#41226)
Package updates
v0.21.0 (2023-11-11)
v0.21.0
is a major feature release.
Features in this release
-
Better error messages with condition chaining
In v0.18, we added better error messages that could tell you what problem happened, but they couldn't tell you why it happened.
0.21
adds condition chaining to the solver, and Spack can now trace back through the conditions that led to an error and build a tree of causes potential causes and where they came from. For example:$ spack solve hdf5 ^cmake@3.0.1 ==> Error: concretization failed for the following reasons: 1. Cannot satisfy 'cmake@3.0.1' 2. Cannot satisfy 'cmake@3.0.1' required because hdf5 ^cmake@3.0.1 requested from CLI 3. Cannot satisfy 'cmake@3.18:' and 'cmake@3.0.1 required because hdf5 ^cmake@3.0.1 requested from CLI required because hdf5 depends on cmake@3.18: when @1.13: required because hdf5 ^cmake@3.0.1 requested from CLI 4. Cannot satisfy 'cmake@3.12:' and 'cmake@3.0.1 required because hdf5 depends on cmake@3.12: required because hdf5 ^cmake@3.0.1 requested from CLI required because hdf5 ^cmake@3.0.1 requested from CLI
More details in #40173.
-
OCI build caches
You can now use an arbitrary OCI registry as a build cache:
$ spack mirror add my_registry oci://user/image # Dockerhub $ spack mirror add my_registry oci://ghcr.io/haampie/spack-test # GHCR $ spack mirror set --push --oci-username ... --oci-password ... my_registry # set login creds $ spack buildcache push my_registry [specs...]
And you can optionally add a base image to get runnable images:
$ spack buildcache push --base-image ubuntu:23.04 my_registry python Pushed ... as [image]:python-3.11.2-65txfcpqbmpawclvtasuog4yzmxwaoia.spack $ docker run --rm -it [image]:python-3.11.2-65txfcpqbmpawclvtasuog4yzmxwaoia.spack
This creates a container image from the Spack installations on the host system, without the need to run
spack install
from aDockerfile
orsif
file. It also addresses the inconvenience of losing binaries of dependencies whenRUN spack install
fails insidedocker build
.Further, the container image layers and build cache tarballs are the same files. This means that
spack install
anddocker pull
use the exact same underlying binaries. If you previously usedspack install
inside ofdocker build
, this feature helps you save storage by a factor two.More details in #38358.
-
Multiple versions of build dependencies
Increasingly, complex package builds require multiple versions of some build dependencies. For example, Python packages frequently require very specific versions of
setuptools
,cython
, and sometimes different physics packages require different versions of Python to build. The concretizer enforced that every solve was unified, i.e., that there only be one version of every package. The concretizer now supports "duplicate" nodes for build dependencies, but enforces unification through transitive link and run dependencies. This will allow it to better resolve complex dependency graphs in ecosystems like Python, and it also gets us very close to modeling compilers as proper dependencies.This change required a major overhaul of the concretizer, as well as a number of performance optimizations. See #38447, #39621.
-
Cherry-picking virtual dependencies
You can now select only a subset of virtual dependencies from a spec that may provide more. For example, if you want
mpich
to be yourmpi
provider, you can be explicit by writing:hdf5 ^[virtuals=mpi] mpich
Or, if you want to use, e.g.,
intel-parallel-studio
forblas
along with an external
lapack
likeopenblas
, you could write:strumpack ^[virtuals=mpi] intel-parallel-studio+mkl ^[virtuals=lapack] openblas
The
virtuals=mpi
is an edge attribute, and dependency edges in Spack graphs now track which virtuals they satisfied. More details in #17229 and #35322.Note for packaging: in Spack 0.21
spec.satisfies("^virtual")
is true if and only if the package specifiesdepends_on("virtual")
. This is different from Spack 0.20, where depending on a provider implied depending on the virtual provided. See #41002 for an example where^mkl
was being used to test for severalmkl
providers in a package that did not depend onmkl
. -
License directive
Spack packages can now have license metadata, with the new
license()
directive:license("Apache-2.0")
Licenses use SPDX identifiers, and you can use SPDX expressions to combine them:
license("Apache-2.0 OR MIT")
Like other directives in Spack, it's conditional, so you can handle complex cases like Spack itself:
license("LGPL-2.1", when="@:0.11") license("Apache-2.0 OR MIT", when="@0.12:")
-
spack deconcretize
commandWe are getting close to having a
spack update
command for environments, but we're not quite there yet. This is the next best thing.spack deconcretize
gives you control over what you want to update in an already concrete environment. If you have an environment built with, say,meson
, and you want to update yourmeson
version, you can run:spack deconcretize meson
and have everything that depends on
meson
rebuilt the next time you runspack concretize
. In a future Spack version, we'll handle all of this in a single command, but for now you can use this to drop bits of your lockfile and resolve your dependencies again. More in #38803. -
UI Improvements
The venerable
spack info
command was looking shabby compared to the rest of Spack's UI, so we reworked it to have a bit more flair.spack info
now makes much better use of terminal space and shows variants, their values, and their descriptions much more clearly. Conditional variants are grouped separately so you can more easily understand how packages are structured. More in #40998.spack checksum
now allows you to filter versions from your editor, or by version range. It also notifies you about potential download URL changes. See #40403. -
Environments can include definitions
Spack did not previously support using
include:
with The definitions section of an environment, but now it does. You can use this to curate lists of specs and more easily reuse them across environments. See #33960. -
Aliases
You can now add aliases to Spack commands in
config.yaml
, e.g. this might enshrine your favorite args tospack find
asspack f
:config: aliases: f: find -lv
See #17229.
-
Improved autoloading of modules
Spack 0.20 was the first release to enable autoloading of direct dependencies in module files.
The downside of this was that
module avail
andmodule load
tab completion would show users too many modules to choose from, and many users disabled generating modules for dependencies throughexclude_implicits: true
. Further, it was necessary to keep hashes in module names to avoid file name clashes.In this release, you can start using
hide_implicits: true
instead, which exposes only explicitly installed packages to the user, while still autoloading dependencies. On top of that, you can safely usehash_length: 0
, as this config now only applies to the modules exposed to the user -- you don't have to worry about file name clashes for hidden dependencies.Note: for
tcl
this feature requires Modules 4.7 or higher. -
Updated container labeling
Nightly Docker images from the
develop
branch will now be tagged as:develop
and:nightly
The:latest
tag is no longer associated with:develop
, but with the latest stable release. Releases will be tagged with:{major}
,:{major}.{minor}
and:{major}.{minor}.{patch}
.ubuntu:18.04
has also been removed from the list of generated Docker images, as it is no longer supported. See #40593.
Other new commands and directives
spack env activate
without arguments now loads adefault
environment that you do not have to create (#40756).spack find -H
/--hashes
: a new shortcut for pipingspack find
output to other commands (#38663)- Add
spack checksum --verify
, fix--add
(#38458) - New
default_args
context manager factors out common args for directives (#39964) spack compiler find --[no]-mixed-toolchain
lets you easily mixclang
andgfortran
on Linux (#40902)
Performance improvements
spack external find
execution is now much faster (#39843)spack location -i
now much faster on success (#40898)- Drop redundant rpaths post install (#38976)
- ASP-based solver: avoid cycles in clingo using hidden directive (#40720)
- Fix multiple quadratic complexity issues in environments (#38771)
Other new features of note
- archspec: update to v0.2.2, support for Sapphire Rapids, Power10, Neoverse V2 (#40917)
- Propagate variants across nodes that don't have that variant (#38512)
- Implement fish completion (#29549)
- Can now distinguish between source/binary mirror; don't ping mirror.spack.io as much (#34523)
- Improve status reporting on install (add [n/total] display...
v0.20.3 (2023-10-31)
v0.20.2 (2023-10-03)
Features in this release
Spack now supports Python 3.12 (#40155)
Bugfixes
- Improve escaping in Tcl module files (#38375)
- Make repo cache work on repositories with zero mtime (#39214)
- Ignore errors for newer, incompatible buildcache version (#40279)
- Print an error when git is required, but missing (#40254)
- Ensure missing build dependencies get installed when using
spack install --overwrite
(#40252) - Fix an issue where Spack freezes when the build process unexpectedly exits (#39015)
- Fix a bug where installation failures cause an unrelated
NameError
to be thrown (#39017) - Fix an issue where Spack package versions would be incorrectly derived from git tags (#39414)
- Fix a bug triggered when file locking fails internally (#39188)
- Prevent "spack external find" to error out when a directory cannot be accessed (#38755)
- Fix multiple performance regressions in environments (#38771)
- Add more ignored modules to
pyproject.toml
formypy
(#38769)
v0.20.1 (2023-07-10)
Spack Bugfixes
- Spec removed from an environment where not actually removed if
--force
was not given (#37877) - Speed-up module file generation (#37739)
- Hotfix for a few recipes that treat CMake as a link dependency (#35816)
- Fix re-running stand-alone test a second time, which was getting a trailing spurious failure (#37840)
- Fixed reading JSON manifest on Cray, reporting non-concrete specs (#37909)
- Fixed a few bugs when generating Dockerfiles from Spack (#37766,#37769)
- Fixed a few long-standing bugs when generating module files (#36678,#38347,#38465,#38455)
- Fixed issues with building Python extensions using an external Python (#38186)
- Fixed compiler removal from command line (#38057)
- Show external status as [e] (#33792)
- Backported
archspec
fixes (#37793) - Improved a few error messages (#37791)
Full Changelog: v0.20.0...v0.20.1
v0.20.0
v0.20.0 (2023-05-21)
v0.20.0
is a major feature release.
Features in this release
-
requires()
directive and enhanced package requirementsWe've added some more enhancements to requirements in Spack (#36286).
There is a new
requires()
directive for packages.requires()
is the opposite of
conflicts()
. You can use it to impose constraints on this package when certain
conditions are met:requires( "%apple-clang", when="platform=darwin", msg="This package builds only with clang on macOS" )
More on this in the docs.
You can also now add a
when:
clause torequires:
in yourpackages.yaml
configuration or in an environment:packages: openmpi: require: - any_of: ["%gcc"] when: "@:4.1.4" message: "Only OpenMPI 4.1.5 and up can build with fancy compilers"
More details can be found here
-
Exact versions
Spack did not previously have a way to distinguish a version if it was a prefix of
some other version. For example,@3.2
would match3.2
,3.2.1
,3.2.2
, etc. You
can now match exactly3.2
with@=3.2
. This is useful, for example, if you need
to patch only the3.2
version of a package. The new syntax is described in the docs.Generally, when writing packages, you should prefer to use ranges like
@3.2
over
the specific versions, as this allows the concretizer more leeway when selecting
versions of dependencies. More details and recommendations are in the packaging guide.See #36273 for full details on the version refactor.
-
New testing interface
Writing package tests is now much simpler with a new test interface.
Writing a test is now as easy as adding a method that starts with
test_
:class MyPackage(Package): ... def test_always_fails(self): """use assert to always fail""" assert False def test_example(self): """run installed example""" example = which(self.prefix.bin.example) example()
You can use Python's native
assert
statement to implement your checks -- no more
need to fiddle withrun_test
or other test framework methods. Spack will
introspect the class and runtest_*
methods when you runspack test
, -
More stable concretization
-
Now,
spack concretize
will only concretize the new portions of the environment
and will not change existing parts of an environment unless you specify--force
.
This has always been true forunify:false
, but not forunify:true
and
unify:when_possible
environments. Now it is true for all of them (#37438, #37681). -
The concretizer has a new
--reuse-deps
argument that only reuses dependencies.
That is, it will always treat the roots of your environment as it would with
--fresh
. This allows you to upgrade just the roots of your environment while
keeping everything else stable (#30990).
-
-
Weekly develop snapshot releases
Since last year, we have maintained a buildcache of
develop
at
https://binaries.spack.io/develop, but the cache can grow to contain so many builds
as to be unwieldy. When we get a stabledevelop
build, we snapshot the release and
add a corresponding tag the Spack repository. So, you can use a stack from a specific
day. There are now tags in the spack repository like:develop-2023-05-14
develop-2023-05-18
that correspond to build caches like:
We plan to store these snapshot releases weekly.
-
Specs in buildcaches can be referenced by hash.
- Previously, you could run
spack buildcache list
and see the hashes in
buildcaches, but referring to them by hash would fail. - You can now run commands like
spack spec
andspack install
and refer to
buildcache hashes directly, e.g.spack install /abc123
(#35042)
- Previously, you could run
-
New package and buildcache index websites
Our public websites for searching packages have been completely revamped and updated.
You can check them out here:- Package Index: https://packages.spack.io
- Buildcache Index: https://cache.spack.io
Both are searchable and more interactive than before. Currently major releases are
shown; UI for browsingdevelop
snapshots is coming soon. -
Default CMake and Meson build types are now Release
Spack has historically defaulted to building with optimization and debugging, but
packages likellvm
can be enormous with debug turned on. Our default build type for
all Spack packages is nowRelease
(#36679, #37436). This has a number of benefits:- much smaller binaries;
- higher default optimization level; and
- defining
NDEBUG
disables assertions, which may lead to further speedups.
You can still get the old behavior back through requirements and package preferences.
Other new commands and directives
spack checksum
can automatically add new versions to package (#24532)- new command:
spack pkg grep
to easily search package files (#34388) - New
maintainers
directive (#35083) - Add
spack buildcache push
(alias tobuildcache create
) (#34861) - Allow using
-j
to control the parallelism of concretization (#37608) - Add
--exclude
option to 'spack external find' (#35013)
Other new features of note
- editing: add higher-precedence
SPACK_EDITOR
environment variable - Many YAML formatting improvements from updating
ruamel.yaml
to the latest version
supporting Python 3.6. (#31091, #24885, #37008). - Requirements and preferences should not define (non-git) versions (#37687, #37747)
- Environments now store spack version/commit in
spack.lock
(#32801) - User can specify the name of the
packages
subdirectory in repositories (#36643) - Add container images supporting RHEL alternatives (#36713)
- make version(...) kwargs explicit (#36998)
Notable refactors
- buildcache create: reproducible tarballs (#35623)
- Bootstrap most of Spack dependencies using environments (#34029)
- Split
satisfies(..., strict=True/False)
into two functions (#35681) - spack install: simplify behavior when inside environments (#35206)
Binary cache and stack updates
- Major simplification of CI boilerplate in stacks (#34272, #36045)
- Many improvements to our CI pipeline's reliability
Removals, Deprecations, and disablements
- Module file generation is disabled by default; you'll need to enable it to use it (#37258)
- Support for Python 2 was deprecated in
v0.19.0
and has been removed.v0.20.0
only
supports Python 3.6 and higher. - Deprecated target names are no longer recognized by Spack. Use generic names instead:
graviton
is nowcortex_a72
graviton2
is nowneoverse_n1
graviton3
is nowneoverse_v1
blacklist
andwhitelist
in module configuration were deprecated inv0.19.0
and are
removed in this release. Useexclude
andinclude
instead.- The
ignore=
parameter of theextends()
directive has been removed. It was not used by
any builtin packages and is no longer needed to avoid conflicts in environment views (#35588). - Support for the old YAML buildcache format has been removed. It was deprecated in
v0.19.0
(#34347). spack find --bootstrap
has been removed. It was deprecated inv0.19.0
. Usespack --bootstrap find
instead (#33964).spack bootstrap trust
andspack bootstrap untrust
are now removed, having been
deprecated inv0.19.0
. Usespack bootstrap enable
andspack bootstrap disable
.- The
--mirror-name
,--mirror-url
, and--directory
options to buildcache and
mirror commands were deprecated inv0.19.0
and have now been removed. They have been
replaced by positional arguments (#37457). - Deprecate
env:
as top level environment key (#37424) - deprecate buildcache create --rel, buildcache install --allow-root (#37285)
- Support for very old perl-like spec format strings (e.g.,
$_$@$%@+$+$=
) has been
removed (#37425). This was deprecated in inv0.15
(#10556).
Notable Bugfixes
- bugfix: don't fetch package metadata for unknown concrete specs (#36990)
- Improve package source code context display on error (#37655)
- Relax environment manifest filename requirements and lockfile identification criteria (#37413)
installer.py
: drop build edges of installed packages by default (#36707)- Bugfix: package requirements with git commits (#35057, #36347)
- Package requirements: allow single specs in requirement lists (#36258)
- conditional variant values: allow boolean (#33939)
- spack uninstall: follow run/link edges on --dependents (#34058)
Spack community stats
- 7,179 total packages, 499 new since
v0.19.0
- 329 new Python packages
- 31 new R packages
- 336 people contributed to this release
- 317 committers to packages
- 62 committers to core
v0.19.2
v0.19.2 (2023-04-04)
Spack Bugfixes
- Ignore global variant requirement for packages that do not define it (#35037)
- Compiler wrapper: improved parsing of linker arguments (#35929, #35912)
- Do not detect apple-clang as cce on macOS (#35974)
- Views: fix support for optional Python extensions (#35489)
- Views: fix issue where Python executable gets symlinked instead of copied (#34661)
- Fix a bug where tests were not added when concretizing together (#35290)
- Compiler flags: fix clang/apple-clang c/c++ standard flags (#35062)
- Increase db timeout from 3s to 60s to improve stability of parallel installs (#35517)
- Buildcache: improve error handling in downloads (#35568)
- Module files for packages installed from buildcache have long placeholder paths abbreviated in configure args section (#36611)
- Reduce verbosity of error messages regarding non-existing module files (#35502)
- Ensure file with build environment variables is truncated when writing to it (#35673)
spack config update
now works on active environments (#36542)- Packages UPC++ and GASNet-EX were updated (#36629)
v0.19.1
v0.19.1 (2023-02-07)
Spack Bugfixes
buildcache create
: make "file exists" less verbose (#35019)spack mirror create
: don't change paths to urls (#34992)- Improve error message for requirements (#33988)
- uninstall: fix accidental cubic complexity (#34005)
- scons: fix signature for
install_args
(#34481) - Fix
combine_phase_logs
text encoding issues (#34657) - Use a module-like object to propagate changes in the MRO, when setting build env (#34059)
- PackageBase should not define builder legacy attributes (#33942)
- Forward lookup of the "run_tests" attribute (#34531)
- Bugfix for timers (#33917, #33900)
- Fix path handling in prefix inspections (#35318)
- Fix libtool filter for Fujitsu compilers (#34916)
- Bug fix for duplicate rpath errors on macOS when creating build caches (#34375)
- FileCache: delete the new cache file on exception (#34623)
- Propagate exceptions from Spack python console (#34547)
- Tests: Fix a bug/typo in a
config_values.py
fixture (#33886) - Various CI fixes (#33953, #34560, #34560, #34828)
- Docs: remove monitors and analyzers, typos (#34358, #33926)
- bump release version for tutorial command (#33859)