| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* mpich: remove unnecessary tuples
* remove redundant :3.3.99 upperbound
|
|
* qt: new version 5.15.11
* qt: open end patch for qtlocation when gcc-10:
|
|
This PR implements the concept of "default environment", which doesn't have to be
created explicitly. The aim is to lower the barrier for adopting environments.
To (create and) activate the default environment, run
```
$ spack env activate
```
This mimics the behavior of
```
$ cd
```
which brings you to your home directory.
This is not a breaking change, since `spack env activate` without arguments
currently errors. It is similar to the already existing `spack env activate --temp`
command which always creates an env in a temporary directory, the difference
is that the default environment is a managed / named environment named `default`.
The name `default` is not a reserved name, it's just that `spack env activate`
creates it for you if you don't have it already.
With this change, you can get started with environments faster:
```
$ spack env activate [--prompt]
$ spack install --add x y z
```
instead of
```
$ spack env create default
==> Created environment 'default in /Users/harmenstoppels/spack/var/spack/environments/default
==> You can activate this environment with:
==> spack env activate default
$ spack env activate [--prompt] default
$ spack install --add x y z
```
Notice that Spack supports switching (but not stacking) environments, so the
parallel with `cd` is pretty clear:
```
$ spack env activate named_env
$ spack env status
==> In environment named_env
$ spack env activate
$ spack env status
==> In environment default
```
|
|
* Add command suggestions
This adds suggestions of similar commands in case users mistype a
command. Before:
```
$ spack spack
==> Error: spack is not a recognized Spack command or extension command; check with `spack commands`.
```
After:
```
$ spack spack
==> Error: spack is not a recognized Spack command or extension command; check with `spack commands`.
Did you mean one of the following commands?
spec
patch
```
* Add package name suggestions
* Remove suggestion to run spack clean -m
|
|
This completes to `spack concretize`:
```
spack conc<tab>
```
but this still gets hung up on the difference between `concretize` and `concretise`:
```
spack -e . conc<tab>
```
We were checking `"$COMP_CWORD" = 1`, which tracks the word on the command line
including any flags and their args, but we should track `"$COMP_CWORD_NO_FLAGS" = 1` to
figure out if the arg we're completing is the first real command.
|
|
|
|
This PR adds support for including separate definitions from `spack.yaml`.
Supporting the inclusion of files with definitions enables user to make
curated/standardized collections of packages that can re-used by others.
|
|
|
|
|
|
Currently module globals aren't set before running
`setup_[dependent_]run_environment` to compute environment modifications
for module files. This commit fixes that.
|
|
|
|
|
|
|
|
The download URL for linux-headers was hardcoded to 4.x;
we need to derive the correct URL from the version number.
|
|
Looking at the memory profiles of concurrent solves
for environment with unify:false, it seems memory
is only ramping up.
This exchange in the potassco mailing list:
https://sourceforge.net/p/potassco/mailman/potassco-users/thread/b55b5b8c2e8945409abb3fa3c935c27e%40lohn.at/#msg36517698
Seems to suggest that clingo doesn't release memory
until end of the application.
Since when unify:false we distribute work to processes,
here we give a maxtaskperchild=1, so we clean memory
after each solve.
|
|
|
|
Don't encourage use of default value if propagating a multivalued variant.
|
|
|
|
0.5.0 tarball now has the 'v' removed from the name
|
|
|
|
Some providers must provide virtuals "together", i.e.
if they provide one virtual of a set, they must be the
providers also of the others.
There was a bug though, where we were not checking if
the other virtuals in the set were needed at all in
the DAG.
This commit fixes the bug.
|
|
|
|
* py-spython: updating to @0.3.1
* Adding `when=` for py-semver
---------
Co-authored-by: LMS Bioinformatics <bioinformatics@lms.mrc.ac.uk>
|
|
|
|
Co-authored-by: wspear <wjspear@gmail.com>
|
|
* mfem: add logic to find CUDA math-libs when using HPC SDK installation
* [@spackbot] updating style on behalf of v-dobrev
|
|
enables loading of SVG icons by providing plugin used by qt-base
|
|
|
|
* libtheora: regenerate Makefile.in during autoreconf
The patch to inhibit running of configure would exit autogen.sh so early
that it did not yet run autoconf/automake/...
Instead of patching autogen.sh, just pass -V as argument, as this is
passed on to configure and lets it just print its version instead of
configuring the build tree.
Also drop arguments from autogen.sh, as they are unused when configure
does not run.
* libtheora: fix build on macos
Apply upstream patches in order to avoid unresolved symbols during building of libtheoraenc.
These patches require re-running automake/autoconf/...
Error messages:
libtool: link: /Users/ma/git/spack/lib/spack/env/clang/clang -dynamiclib -o .libs/libtheoraenc.1.dylib .libs/apiwrapper.o .libs/fragment.o .libs/idct.o .libs/internal.o .libs/state.o .libs/quant.o .l
ibs/analyze.o .libs/fdct.o .libs/encfrag.o .libs/encapiwrapper.o .libs/encinfo.o .libs/encode.o .libs/enquant.o .libs/huffenc.o .libs/mathops.o .libs/mcenc.o .libs/rate.o .libs/tokenize.o -L/opt/spac
k/darwin-sonoma-m1/apple-clang-15.0.0/libtheora-1.1.1-uflq3jvysewnrmlj5x5tvltst65ho3v4/lib -logg -lm -Wl,-exported_symbols_list -Wl,/var/folders/zv/qr55pmd9065glf0mcltpx5bm000102/T/ma/spack-stage/spac
k-stage-libtheora-1.1.1-uflq3jvysewnrmlj5x5tvltst65ho3v4/spack-src/lib/theoraenc.exp -install_name /opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/libtheora-1.1.1-uflq3jvysewnrmlj5x5tvltst65ho3v4/lib
/libtheoraenc.1.dylib -compatibility_version 3 -current_version 3.2
ld: warning: search path '/opt/spack/darwin-sonoma-m1/apple-clang-15.0.0/libtheora-1.1.1-uflq3jvysewnrmlj5x5tvltst65ho3v4/lib' not found
ld: Undefined symbols:
_th_comment_add, referenced from:
_theora_comment_add in apiwrapper.o
_th_comment_add_tag, referenced from:
_theora_comment_add_tag in apiwrapper.o
_th_comment_clear, referenced from:
_theora_comment_clear in apiwrapper.o
_th_comment_init, referenced from:
_theora_comment_init in apiwrapper.o
_th_comment_query, referenced from:
_theora_comment_query in apiwrapper.o
_th_comment_query_count, referenced from:
_theora_comment_query_count in apiwrapper.o
* libtheora: add git versions
stable as version name for theora-1.1 branch was chosen so that it sorts between 1.1.x and master
* libtheora: remove unused patch
thanks to @michaelkuhn for noticing
|
|
(#40622)
* Add 2023.09-0 for x86_64, aarch64, and ppc64le
extend the anaconda3 package.py to support aarch64 and ppc64le.
add the latest version of anaconda3 to each new platform, including the existing x86_64
* formatting
|
|
Co-authored-by: github-actions <github-actions@users.noreply.github.com>
Co-authored-by: Tom Scogland <scogland1@llnl.gov>
|
|
Co-authored-by: Nicolas Cornu <me@alkino.fr>
|
|
|
|
|
|
* py-pint: new versions 0.21, 0.22
* Address feedback
* Fix dumb typo
* Add typing extension requirement
|
|
|
|
(#40544)
* Fix py-pyside2 to build with newer llvm and to use spack libglx and libxcb headers where system headers are missing
pyside2 needs LLVM_INSTALL_DIR to be set when using llvm 11: and expects system headers for libglx and libxcb and won't build otherwise.
* Fix styling
* remove raw string type
* Update var/spack/repos/builtin/packages/py-pyside2/package.py
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
---------
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
|
|
|
|
* add charliecloud 0.35
* fix linter rage
* fix linter rage?
|
|
Co-authored-by: jmcarcell <jmcarcell@users.noreply.github.com>
|
|
|
|
|
|
Co-authored-by: adamjstewart <adamjstewart@users.noreply.github.com>
|
|
|
|
|
|
The lookup in a dictionary causes KeyError on package load for
unsupported architectures such as i386 and ppc big endian.
|
|
|
|
|
|
|
|
This PR makes it possible to select only a subset of virtual dependencies from a spec that _may_ provide more. To select providers, a syntax to specify edge attributes is introduced:
```
hdf5 ^[virtuals=mpi] mpich
```
With that syntax we can concretize specs like:
```console
$ spack spec strumpack ^[virtuals=mpi] intel-parallel-studio+mkl ^[virtuals=lapack] openblas
```
On `develop` this would currently fail with:
```console
$ spack spec strumpack ^intel-parallel-studio+mkl ^openblas
==> Error: Spec cannot include multiple providers for virtual 'blas'
Requested 'intel-parallel-studio' and 'openblas'
```
In package recipes, virtual specs that are declared in the same `provides` directive need to be provided _together_. This means that e.g. `openblas`, which has:
```python
provides("blas", "lapack")
```
needs to provide both `lapack` and `blas` when requested to provide at least one of them.
## Additional notes
This capability is needed to model compilers. Assuming that languages are treated like virtual dependencies, we might want e.g. to use LLVM to compile C/C++ and Gnu GCC to compile Fortran. This can be accomplished by the following[^1]:
```
hdf5 ^[virtuals=c,cxx] llvm ^[virtuals=fortran] gcc
```
[^1]: We plan to add some syntactic sugar around this syntax, and reuse the `%` sigil to avoid having a lot of boilerplate around compilers.
Modifications:
- [x] Add syntax to interact with edge attributes from spec literals
- [x] Add concretization logic to be able to cherry-pick virtual dependencies
- [x] Extend semantic of the `provides` directive to express when virtuals need to be provided together
- [x] Add unit-tests and documentation
|
