| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
Fixes #5189
When working with non-normalized paths containing ".." on some
file systems, Spack was found to encounter a permission error when
writing to the path. This normalizes a path written by the
intel-parallel-studio package and also normalizes all paths
written by the license install hook (for all packages) to avoid
this issue for intel-parallel-studio.
|
|
|
|
|
|
Spack's hypre package depends on LAPACK and BLAS, so linking to hypre
requires linking to the LAPACK and BLAS libraries used to build hypre.
|
|
Signed-off-by: Howard Pritchard <howardp@lanl.gov>
|
|
Adds the first stable API release of ADIOS2, v.2.1.0.
Also adds a missing `pybind11` CMake flag for proper Python
selection (needed in both the new and previous version).
|
|
To accommodate build systems on Darwin which look for glibtool/ize,
#7060 attempted to provide glibtool/ize symlinks for libtool/ize
but accidentally created the same symlink twice. #7073 reverted this
and replaced libtool/ize with glibtool/ize on Darwin. This led to
#7163 since AutotoolsPackages depend on the presence of the 'libtool'
binary, so this returns to the approach of #7160 but makes the
correct symlinks.
|
|
XBraid installs `libbraid.a`, but the default `libs` method
implementation will search for `libxbraid`, which does not exist. This
commit fixes the behavior of the `libs` method for the `xbraid`
package by overriding package's `libs` method.
|
|
|
|
|
|
|
|
|
|
|
|
Prior to this commit, running `spack module refresh` with `gdbm`
installed throws the warning:
```console
==> Warning: Could not write module file [/Users/oxberry1/spack/share/spack/lmod/darwin-sierra-x86_64/Core/gdbm/1.14.1.lua]
==> Warning: --> global name 'spack_cc' is not defined <--
```
This warning is repeated for every `gdbm` installation in Spack.
The cause of the issue seems to be the same as in spack/spack (#6089):
using `spack_cc`, `spack_cxx`, or similar inside `configure_args`
causes the warnings to throw when module files are generated.
Moving the use of `spack_cc` into `setup_environment` seems to fix the
problem, even though it's a bit of a kludge.
|
|
Running `spack module refresh -m lmod --delete-tree -y` throws the
following warning:
```console
==> Warning: Could not write module file [/Users/oxberry1/spack/share/spack/lmod/darwin-sierra-x86_64/openblas/0.2.20-ibhtl5q/clang/5.0.1/ipopt/3.12.9.lua]
==> Warning: --> global name 'prefix' is not defined <--
```
This warning arises because the variable expansions in
`spack.modules.BaseFileWriter` occur at module/package scope. Even
though `prefix` is an argument to `install` methods in e.g.,
`MakefilePackage`, so using this argument within package methods is
legal, doing so defeats the introspection logic in
`spack.modules.BaseFileWriter`. Replacing `prefix` with `self.prefix`
resolves the problem, because the introspection logic in
`spack.modules.BaseFileWriter` can use introspection to query IPOPT's
prefix.
|
|
|
|
|
|
|
|
Add query parameters to retrieve libraries based on precision (e.g.
double or quad) and mpi/openmp support.
|
|
|
|
|
|
|
|
* Added Nox for Trilinos installation by xSDK
* Enable NOX only for Develop copy
|
|
|
|
Following the discussion with Todd and Adam, find has been modified to
accept glob expressions. This should not affect performance as every
glob implementation I inspected has 3 cases (no wildcard, wildcard but
no directories involved, wildcard and directories involved) and uses
fnmatch underneath.
Mixins have been changed to do by default a non-recursive search (but
a recursive search can still be triggered using the recursive keyword).
|
|
Following a comment from Todd, the search path for the files listed in
`filter_compiler_wrappers` can now be narrowed. Anyhow, the function
implementation still makes use of `find`, the rationale being that we
have already seen packages that install artifacts in e.g. architecture
dependent folders. The possibility to have a relative search path might
be a good compromise between the previous approach and the one suggested
in the review.
Also: 'ignore_absent' and 'backup' keyword arguments can be optionally
forwarded to `filter_file`.
|
|
Following comments from Todd:
- the call to tty.debug has been moved deeper, to log the filtering of each file
- the shadowing on the name "kwargs" is avoided
|
|
|
|
|
|
Implemented a declarative syntax for the additional behavior that can
get attached to classes. Implemented a function to filter compiler
wrappers that uses the mechanism above.
|
|
|
|
Modifications:
* added a mixin to filter compiler wrappers from files
* modified hdf5, openmpi, mpich, mvapich2 to use it
|
|
|
|
- command reference now includes usage for all Spack commands as output
by `spack help`. Each command usage links to any related section in
the docs.
- added `spack commands` command which can list command names,
subcommands, and generate RST docs for commands.
- added `llnl.util.argparsewriter`, which analyzes an argparse parser and
calls hooks for description, usage, options, and subcommands
|
|
- Shorten Spack command usage for short options. Short options are now
shown as [-abc] instead of as [-a] [-b] [-c]
- fix bug that mixed long and short options for top-level `spack help`
|
|
|
|
|
|
- Add proper help for `spack buildcache` subcommands
- Reorganize the help categories of Spack commands so that buildcache is
in packaging and diy and setup are now in build.
|
|
- previously commands with this argument showed a long list of choices
that were platform specific.
- use a better metavar: {defaults,system,site,user}[/PLATFORM]
|
|
|
|
|
|
|
|
|
|
* Remove variants disabling blas and lapack for py-numpy, issues
building these have been resolved
* For CMake greater than 3.10, FindMPI changed, so use
MPIEXE_EXECUTABLE instead of MPIEXE for 3.10 and newer
|
|
I think the main issue here is that we ship a custom version of a system
library (`argparse`), and this is prone to fail if `argparse` is
imported before we hack `sys.path` internally.
Probably a better solution would be not to customize argparse, but
instead have a wrapper on top of whatever the system provides.
|
|
fixes #7128
Before this PR packages that were indirectly dependent on python might
have failed due to inconsistency between the python found in the
environment and the standard libraries set in PYTHONHOME
|
|
|
|
|
