- This moves var/spack/packages to var/spack/repos/builtin/packages.
- Packages that did not exist in the source branch, or were changed in
develop, were moved into var/spack/repos/builtin/packages as part of
the integration.
Conflicts:
lib/spack/spack/test/unit_install.py
var/spack/repos/builtin/packages/clang/package.py
Binutils defines several global variables multiple times. Apparently this works fine under Linux, but it leads to a linker error on Darwin. Rename these global variables.
Note that binutils on OS X is still not really useful, as important tools (e.g. ld) are not supported.
disabled
2. invoke the b2 installation once for each enabled threading option (apparently
the install fails if a single call has both options enabled for mpi)
Add cmake requirement.
Remove gmp and isl requirements. Using an external isl leads to a build failure for me on a fairly standard Fedora Linux workstation. The Spack package file says that isl is required for polly, however, the polly documentation states that as of LLVM 3.7, polly includes isl, and has no external dependencies any more.
Currently, ncurses's include files are installed into two separate subdirectories, "install/ncurses" and "install/ncursesw". The second level of subdirectories ("ncurses" and "ncursesw") are non-standard. I checked several systems to confirm this, and ncurses examples on the web also simply contain "#include <ncurses.h>" instead of "#include <ncurses/ncurses.h>", which would be necessary to use the currently installed ncurses packages. For example, this also breaks llvm, which uses ncurses, but does not expect the second level of subdirectories.
I am now using the option "--enable-overwrite", which installs the header files directly in to ".../include". I also enable "widec" support all the time. These options are e.g. similar to the ones used by MacPorts, and I confirm that they make the llvm package build (which didn't build before).
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.
