- The following now work differently:
spec['mpi']
spec['blas']
This can return a spec for openmpi, mpich, mvapich, etc., EVEN if
the spec is already concretized. This means that in a package that
`depends_on('mpi')`, you can do `spec['mpi']` to see what it was
concretized to. This should simplify MPI and BLAS packages.
'mpi' in spec
'blas' in spec
Previously, if the spec had been concretized, these would be `False`
because there was not a dependency in the DAG with either of these
names. These will now be `True` even if the spec has been
concretized. So, e.g., this will print "YES"
s = Spec('callpath ^mpich')
if 'mpi' in spec:
print "YES"
- Similarly, this will be True:
Spec('mpich').satisfies('mpi')
- Because of the way virtual dependencies are currently implemented,
the above required some fiddling around with `package.py` so that it
would never call `Spec.__contains__` (and result in endless
recursion).
- This should be fixed by allowing virutal dependnecies to have their
own package class.
- This would allow a quicker check for vdeps, without a call to
`all_packages`.
- For the time being, `package.py` shouldn't call `__contains__`
- Expanding archvies like MAGMA 1.6.2 creates extra hidden files that
confuse Spack's staging mechanism.
- Added a special case to ignore hidden files when checking whether
the tarball exploded.
- spack install suppresses build output by default.
- use install -v to show build output on the console too
- package.py uses log_output context to redirect output and log it to a file
- filters color codes out of output written to file
- optionally echos to the terminal
- YAML directory layout knows about its build log.
- can get path to install build log to from directory layout
- Package.install now copies the build log to $prefix/.spack/build.out
- Error message from failed install execution now includes build log location
