The version of LLVM used by flang is new enough that CppBackend doesn't exist. Unfortunately, `flang-xxxxxxxx` is seen as < `3.9.0` by the version check.
* add a special case for `flang` versions.
The default install for llvm should just be the common typical case, i.e.
support for local host and cpu architectures. Enablingsupport for the wide
array of auxiliary architectures should be explicit rather than implicit.
Based on the LLVM documentation [1], Python is used to run the automated
test suite. Therefore is it always a dependency for LLVM. However, if
build without Python (~python), we limit it to a build time dependency.
Note that py-lit is not added as a spack dependency even though it is
available as a spack package. This is because it is already included
in llvm and llvm is difficult to configure using an external py-lit
(several CMake variables to set correctly). Additionally, having
py-lit as a spack dependency adds Python as a runtime dependency
for llvm even though it is not required at runtime.
[1] https://llvm.org/docs/GettingStarted.html#requirements
This avoids using a system-installed CUDA package. In the future a
variant can be added to allow using Spack-installed CUDA, but for
now CUDA support is always disabled.
* llvm: Bump version to 7.0.1
* llvm: Added perl-data-dumper build dependency for openmp
* llvm: Enable exception handling and RTTI
Useful to have turned on in general with RTTI but also necessary
to workaround some lldb stability issues with some versions of
libstdc++.
- remove the old LGPL license headers from all files in Spack
- add SPDX headers to all files
- core and most packages are (Apache-2.0 OR MIT)
- a very small number of remaining packages are LGPL-2.1-only
Replace use of `shutil.copytree` with `copy_tree` and `install_tree` functions in `llnl.util.filesystem`.
- `copy_tree` copies without setting permissions. It should be used to copy files around in the build directory.
- `install_tree` copies files and sets permissions. It should be used to copy files into the installation directory.
- `install` and `copy` are analogous single-file functions.
- add more extensive tests for these functions
- update packages to use these functions.
Flang now uses its own version of llvm and clang (called flang-driver). This is
handled by adding flang-specific versions of the LLVM package and updates flang
to depend on those versions.
* Updated llvm to version 6.0.1. The previous 6.0.0 had an incorrectly declared symbol, discussed at https://reviews.llvm.org/D44140, which, amongst other things, broke py-numba. This version works fine with py-numba.
* Flag the conflict between py-numba and llvm@6.0.0
* Removed a single trailing space to satisfy checks
Fixes#8088#7012 added a @when condition for a @run_before check to constrain
that check to only run on Darwin. @when is intended to be used to
choose one of several different implementations of a given function
and cannot be used to conditionally deactivate a check altogether.
This replaces the external decorator with a check that executes at
the beginning of the function.
* llvm+lldb plaform=darwin: check for lldb_codesign
Building LLVM with LLDB requires that the "lldb_codesign" code
certificate be created (see
https://llvm.org/svn/llvm-project/lldb/trunk/docs/code-signing.txt for
details). This commit checks for this certificate on Darwin if LLDB is
to be built, and returns an informative error message if this
certificate is unavailable.
* Combined llvm and llvm-lld: removed the separate llvm-lld package
and added llvm-lld as an optional add on to the llvm package (the
way several other llvm tools are maintained e.g. lldb)
* Added more lld hashes to llvm package
* The 'CppBackend' target doesn't exist for version 3.9.0 or later
so exclude it for later versions
* Was incorrectly specifying 'sparc' as a target for the 'sparc'
architecture - needed to specify 'Sparc'
* Fix issue #7248 building llvm: don't make the LLVMDemangle target
for llvm < 4.0.0
Since LLVM 3.9 Clang can use the libc++ library by default using the
CLANG_DEFAULT_CXX_STDLIB cmake configuration variable, without having to
specify the -stdlib=libc++ option on the clang++ command line.
This commit makes clang++ use libc++ by default for LLVM 3.9 and later if the
libcxx variant is on.
Fixes#5942.
* Add universal build_type variant to CMakePackage
* Override build_type in some packages with different possible values
* Remove reference to no longer existent debug variant
* Update CBTF packages with new build_type variant
* Keep note on build size of LLVM
* Initial work on flag trapping using functions called <flag>_handler and default_flag_handler
* Update packages so they do not obliterate flags
* Added append to EnvironmentModifications class
* changed EnvironmentModifications to have append_flags method
* changed flag_val to be a tuple
* Increased test coverage
* added documentation of flag handling
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
* Fix for llvm 4.0.0 on centos
This addresses https://github.com/LLNL/spack/issues/3791
* Only enable this option if on linux
* Change condition to satisfy standard
* Provide new versions of llvm.
+ Provide file list and md5 hashes for 3.8.1 and 3.9.0.
+ Clean up indentation for the 'releases' data structure to improve
consistency.
* Adding a block of code to the 'resources' structure for cfe.
* Merge cfe and clang resources into single entity.
Includes :
- treatment of a generic hierarchy (i.e. lapack + mpi + compiler)
- possibility to specify which compilers are to be considered Core
- correct treatment of the 'family' directive
- unit tests for most new features
