Boost does not build on OS X with either gold or binutils. The gold linker does not exist on Darwin, and binutils on Darwin provides an assembler that doesn't work for Boost.
- Introduce a variant that specifies whether to build with binutils, defaulting to true for backward compatibility
- Auto-detect whether we build on Darwin; in this case, set the gold and binutils variant defaults to false
- Clean up configure flags for as and ld
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).
