There are two sensible defaults for building boost libraries: build all of them
or build none of them. Previously the Spack boost package took the first
approach. This commit changes to building no libraries by default. The user can
specify which libraries they need using variants (e.g. +iostreams to compile the
boost iostreams library). If no libraries are built then a header-only install
is performed (no compilation, just copy header files to prefix). The consequence
of this change is that packages which specify a dependency on boost may now fail
(until they are updated to specify exactly which boost libraries they need
compiled).
The user may now specify whether to build shared libraries (static libraries are
always built) and whether to build libraries with/out multi-threading support
(default is to only build with multi-threading support).
The executable on the user-config.jam toolset line is set to Spack's cc script.
Before, without this, the desired toolset was used but Spack deferred to the
boost build system to choose the compiler version.
bzip2 and zlib are always specified as dependencies when iostreams is built
(before this could be controlled with the +compression variant).
PETSc requires Python for building.
I have a case where an HPC system has a very old default Python version, too old for Spack. So I load a module for Python, which makes Spack work. This module relies on LD_LIBRARY_PATH.
When building PETSc, Spack unsets LD_LIBRARY_PATH, breaking the Python that PETSc finds.
Explicitly requiring Python for PETSc makes building PETSc work.
FFTW can build only one floating point precision (float, double, long double, quad) at once, but they can all be installed simultaneously as the libraries have different names. It is common packages to decide only at run time which precision FFTW they need, and thus FFTW should offer all precisions at once.
The gold linker support and gold plugin variants now use the same name.
Trying to apply use-flag-style discipline here despite the fact gold has
other implications for clang, this way globally enabling gold will have
a more consistent effect if that becomes possible. The gold support in
gcc could use more testing to ensure it works consistently, but as long
as a binutils including gold is used the gcc configure tends to pick it
up, and it seems to work with 5.3.0 at least.
This update significantly reworks the llvm and clang packages. The llvm
package now includes variants allowing it to build and install any and
all of:
* clang
* lldb
* llvm's libunwind (why, WHY did they name it this?!?)
* polly (including building it directly into the clang tools, 3.7.0 only)
* clang extra tools
* compiler-rt (sanitizers)
* clang lto (the gold linker plugin that allows same to work)
* libcxx/libcxxabi
* libopenmp, also setting the default openmp runtime to same, when
parameters happen this shoudl be an option of libomp or libgomp
Ideally, this should have rpath setup like the gcc package does, but
clang's driver has no support for specs as such, and no clearly
equivalent mechanism either. If anyone has ideas on this, they would be
welcome.
One significant note related to gcc though, if you test this on LLNL
systems, or anywhere that has multiple GCCs straddling the dwarf2
boundary and sharing a libstdc++, build a gcc with spack and use that to
build clang. If you use a gcc4.8+ to build this with an older
libstdc++ it will fail on missing unwind symbols because of the
discrepancy.
Resource handling has been changed slightly to move the unpacked archive
into the target rather than use symlinks, because symlinks break certain
kinds of relative paths, and orders resource staging such that nested
resources are unpacked after outer ones.
A pile of libraries and tools, libedit is actually important as a
replacement of readline for non-GPL projects. Also ninja may be
worthwhile for some of the larger CMake projects, like llvm/clang.
- Adding `preferred=True` to a version directive will change its sort
order in concretization.
- This provides us a rudimentary ability to keep the Spack stack
stable as new versions are added.
- Having multiple stacks will come next, but this at least allows us
to specify default versions of things instead of always taking the
newest.
