Although it hurts a little, officially pre-compiled headers in
boost are only supported for gcc & msvc and the latest clang
releases still fail to build boost with it.
Therefore, I disabled building those to get boost build with
clang 3.9.0 on an Ubuntu 14.04 (x86).
Links to documentation and boost bug reports are inline, so
people can later on check if they still apply. Seems just to
be a bug in `Boost.Build` that tries to set `-o` with multiple
output files.
* Tells boost explictly about libraries and headers
Ideally, bjam would determine the libraries and headers from the
executable. But it doesn't. This rigs a best guess for python libraries
and headers.
* Move glob import to top of file
* variable name change: alllibs --> all_libs
* Use dso suffix rather than hard-coded string
* Use only MAJOR.MINOR when setting up python in bjam
* dealii: add missing python dependency
* boost: fix a bug which broke it on macOS with clang+gfortran
Boost was using gcc compiler instead of clang++, which lead to
cryptic Undefined symbols linking errors for boost::python::objects::function_object()
when building other packages against boost+python.
* boost: add exceptions for intel
* boost: use spack_cxx
2. clarify comment for default_noinstall_libs
3. renamed regex_icu variant to icu_support (both the locale and regex libs can
use it)
4. explicitly set b2 install ICU_PATH when regex_icu is activated
- 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
Package repositories now look like this:
top-level-dir/
repo.yaml
packages/
libelf/
package.py
mpich/
package.py
...
This leaves room at the top level for additional metadata, source,
per-repo configs, indexes, etc., and it makes it easy to see that
something is a spack repo (just look for repo.yaml and packages).
