When Spack installs a package it writes the package.py file and
patches to a separate repository (which reflects the state of the
package at the time it was installed). Previously, Spack only wrote
patches that were used at installation time. This updates the
archiving step to include all patch files that are relevant to the
package (in case that repository is used in another context).
Change the depends_on type from default (build + link) to just 'link'
for binutils and a few other packages. We don't use the binutils
utilities (only libs). On cori at NERSC (Cray), this was breaking the
build by covering up the system ld.
* Only apply issue-87.patch for versions before 1.2.3
* 1.2.3 builds fine with gcc@8:, but 1.2.2 and 1.2.2_p1 both fail
(with or without the patch) so the conflict is updated to exclude
only these two versions.
This commit removes redundant calls to `libtoolize` and `aclocal`.
Some configurations, such as a Spack user using macOS with a
Homebrew-installed `libtool` added to their `packages.yaml`, have
`autoreconf` and GNU libtoolize installed as `glibtoolize`, but not
`libtoolize`. While Spack installations of `libtool` built from source
would install `glibtoolize` and symlink `libtoolize` to `glibtoolize`,
an external installation of GNU libtoolize as `glibtoolize` will not
have such a symlink, and thus the call `m.libtoolize()` will throw an
error because `libtoolize` does not exist at the path referenced by
`m.libtoolize()` (i.e.,
`self.spec['libtool'].prefix.bin.join('libtoolize')).
However, on these same systems, `autoreconf` runs correctly, and calls
`glibtoolize` instead of `libtoolize`, when appropriate. Thus,
removing the call to `libtoolize` should resolve the error mentioned
above.
The redundant call to `aclocal` is also removed in this commit because
the maintainers of GNU Automake state that "`aclocal` is expected to
disappear" and suggest that downstream users never call `aclocal`
directly -- rather, they suggest calling `autoreconf` instead.
* Make mpi, scipy, petsc4py, and nlopt support optional
* Later versions depend on python@3.5:
* Versions before 0.4.1 must build with MPI: add a conflict for
@:0.4.1~mpi
Before this commit, CMake would still attempt to detect OpenMP, even
if RAJA were being installed with `spack install raja~openmp`, because
the option `ENABLE_OPENMP` is set to "On" by default. This commit
explicitly disables OpenMP when the Spack install spec contains
'~openmp`, ensuring that CMake does not attempt to detect and link
with OpenMP.
