Certain remote protocols don't support the `--depth` option. Since this can't
be checked by URL type or in any sane way locally, this version attempts to
clone git repositories with the --depth option, and if that fails attempts the
clone again without it.
Ensures all tags are ready before checkout, using `--branch` if possible and
an extra pull if that is not available. Also adds `--depth 1` to create
shallow clones if the git version is sufficient.
Fixes#64.
It is currently less painful to pull the source from github, compile it into a
gem, then install the gem, than it is to download a gem and install it. This
still lacks an activation mechanism, but `spack use tmuxinator` is functional.
- This can result in the user being prompted to download an unsafe
version.
- Avoids overly strict errors when something *could* be satisfiable
but we don't know about hte version.
- 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
This includes:
- Much better variant support (+debug/-debug)
- Optional dependency support (depends_on(... , when='<condition>')
- New config file format (YAML in ~/.spack)
- New Spec format (YAML in $prefix/.spack/spec.yaml)
- Can depend conditionally based on variant, compiler, arch, deps, etc
- normalize() is not iterative yet: no chaining depends_ons
- really need a SAT solver, but iterative will at least handle
simple cases.
- Added "strict" option to Spec.satisfies()
- strict checks that ALL of other's constraints are met (not just
the ones self shares)
- Consider splitting these out into two methods: could_satisfy() and
satisfies()
- didn't do this yet as it would require changing code that uses
satisfies()
- Changed semantics of __contains__ to use strict satisfaction (SPACK-56)
- Added tests for optional dependencies.
- The constrain() method on Specs, compilers, versions, etc. now
returns whether the spec changed as a result of the call.
- Variant concretization is tricky:
- During concretization, a spec without variants (e.g., mpich) means
"don't care". So, Spec('mpich').satisfies('mpich+debug') is true
because it *could* still be built that way.
- After concretization, a spec without a particular variant means
"don't know", as that wasn't part of the spec, so the opposite
relationship is true. Assume 'spec' is already installed:
spec.satisfies('mpich+debug')
this is false beacuse the `debug` variant didn't exist when spec
was built, so we can't satisfy the explicit request for +debug.
- Variants are now declarable in packages using the variant() directive.
- Variants are checked - you can't just ask for a random variant, it has to be declared.
- conditional logic (@when, if, '+debug' in spec, etc.) still required in package to
implement variant.
