* r-glmnet: Create New Package.
* pr-quantities: add version & py-numpy conflict (#5307)
* r-glmnet: Update version to 2.0-13
* r-matrix: Update version to 1.2-11
* r-lattice: Update version to 0.20-35.
The default implementation of Package.fetch_remote_versions will take
a URL like https://github.com/google/protobuf/archive/ and automatically
search https://github.com/google/protobuf/releases/ for new package
versions. In the case of protobuf the release/ path contains release
artifacts for a version and the archive/ path contains the desired
source. Since both are associated with the version, and
Package.fetch_remote_versions only stores one URL for a given version,
the two paths are in conflict; previously the URL returned for a
given version was arbitrarily chosen between the two paths. This
updates the definition for the Protobuf package to always search for
URLs in https://github.com/google/protobuf/archive/
closes#5201
Currently, if a user sets an external package to have a prefix that is
one of the system paths (like '/usr') the module files that are
generated will prepend '/usr/bin' to 'PATH', etc. This is particularly
nasty at the time when a module file is unloaded, and e.g. paths like
'/usr/bin' will be discarded from PATH.
This PR solves the issue skipping system paths when a prefix inspection
is made to generate module files.
* blas_lapack: add multithreading variant
* elemental: update
* intel-mkl: extend to macOS
* rename multithreading to threads
* intel-mkl: avoid long lines
* intel-mkl: make one install error a conflict
* openblas: fix a minor bug in the test
Update the git package to git@2.14.1.
This requires a pcre that has been built with `--enable-jit`, so this
adds a variant to pcre to support that and arranges so that git versions
before 2.14 depend on pcre and git 2.14 and after depend on pcre+jit.
Due to the logic in configure.ac, we may be using both the system
linker (LD_RO='ld -r -o') and the linker tied to the compiler (LD=$CXX).
This may produce weird link-time errors when the two executables are
not the same.
The PR works around the issue disabling 'ld -r'
Open MPI has been relying on versions of PMIx since the 2.0.0
release. Although the embedded version can be used, it makes
more sense long term for Spack to know about the PMIx package,
and to build Open MPI against PMIx as an external package.
There are other software components that may eventually be
reliant on PMIx including MPICH, GASNet, the OpenSHMEM reference
implementation, etc.
This is also partly motivated by the desire to have ECP ST
projects to be released through Spack.
Signed-off-by: Howard Pritchard <howardp@lanl.gov>
