* extend Prefix class with join() member to support dynamic directories
* add more tests for Prefix.join()
* more tests for Prefix.join()
* add docstring
* add example to docstring of Prefix class
* cleanup Prefix.join() tests
* use Prefix.join() in Packaging Guide
The URL that we were using for pigz only provides the current
version. When the author released v2.4 the package became
uninstallable (unless you have the tarball cached).
It turns out that their are tarballs of the tagged source tree
available on GitHub and they're sufficient to build things (no
additional bits needed).
This commit switches the URL to the GitHub archive URL.
Sadly, this changes the v2.3.4 digest, but that version was no longer
available/install-able anyway, so "net-net we're still in positive
territory".
Installing the current version of Picard fails with:
```
==> Error: Unable to parse extension from https://github.com/broadinstitute/picard/releases/download/2.18.3/picard.jar.
If this URL is for a tarball but does not include the file extension
in the name, you can explicitly declare it with the following syntax:
version('1.2.3', 'hash', extension='tar.gz')
If this URL is for a download like a .jar or .whl that does not need
to be expanded, or an uncompressed installation script, you can tell
Spack not to expand it with the following syntax:
version('1.2.3', 'hash', expand=False)
```
Fix it, but adding `expand=False`, like the other versions.
Fixes#8217
Trying to relocate a distribution when the new and old paths are
equal leads to failure, because the test that ensures that no
unrelocated bits are left over always fails. As an example, this
occurs if a user installs a package, generates a binary with it
using 'spack buildcache', uninstalls it, and then attempts to
reinstall into the same spack installation using the generated
binary package.
This updates the relocation check to accept the presence of the
old prefix in binaries if the package is being reinstalled into
its original location.
* fix missing -lrt for Centos6, issue: #7552
* fix missing -lrt for Centos6, issue: #7552
* fix using make() as opposed to patching
* remove patch, as the fix is provided withing package.py instead
* make flake8 happy
* allow user to constrain dependencies that are added conditionally
* remove check for not-visited deps from normalize, move it to concretize. The check now runs after the concretization loop completes (so an error is only reported if the user-mentioned spec doesnt appear anywhere in the dag)
* remove separate full_spec_deps variable; rename spec_deps to all_spec_deps to clarify that it merges user-specified dependencies with derived dependencies
* add unit test to confirm new functionality
- `spack config blame` is similar to `spack config get`, but it prints
out the config file and line number that each line of the merged
configuration came from.
- This is a debugging tool for understanding where Spack config settings
come from.
- add tests for config blame
* Update package: add info for emacs@26.1
In addition to the digest, it needs gnutls (perhaps there's a way to
turn it off, but it seems like a Good Thing to encourage, so...).
* Clean up tls variant handling
- Don't to specify the dependency for @26.1:, just need to fix what's
already there.
- Don't assume that configure will DTRT w.r.t. gnutls when it's
discovered in the environmnet, use explicit configure switches.
- Clean up some unnecessary dependencies when +tls. Why would you
need libxpm when building +tls? Will ask the original author about
this.
* Use append when adding configure switches
* Add dependency on pcre
When one builds +X, Spack's pcre is pulled into the build via
the X dependencies. When one builds without it, the build discovers
and links against the system library.
We might as well just depend on it and have a consistent outcome.
The recipe previously did not include -DWITH_JASPER
Other edits:
* BUILD_IPP_IW is BUILD instead of WITH; it was in a different section of the CMakeLists.txt. Move it to the top
* Several options were missing :BOOL, add them
* -DWITH_ZLIB doesn't actually exist as an option, at least in the latest version.
* Added new package Camellia.
* Fixed an issue with a missing blank line.
Added a couple more Trilinos packages (things I expect to depend on eventually).
* Fixed a couple issues raised by @adamjstewart.
* Specified 4.9.2 as the supported MOAB version.
5.0.0 causes build issues on Macs during the link of Camellia's drivers. The issue is that we end up with -framework -lAccelerate in the link line, where it should read -framework Accelerate, I believe. I'm not sure where this comes from, but 4.9.2 does not have this issue.
* Trimmed slightly the Trilinos requirements.
Also deleted a blank line that had spaces in it because the Travis-CI thing didn't like that.
* Reduced length of MOAB description (Travis-CI complained).
* Reduced the MOAB line further; didn't quite get there last time!
This is to satisfy Travis-CI's requirement that the description be less than 80 characters long (E501).
* Put in my GitHub handle, in place of an allusion to my email address.
Also added a new argument for Camellia build, and made the MOAB description longer (thanks to @adamjstewart's note that long lines are allowed so long as they are not split).
* Added MPI dependency.
Added explicit OFF for MOAB enablement when ~moab.
Swapped order of variant and version.
* Add Tophat v2.1.2, fixes automake issues
The Tophat team merged the patch from
https://github.com/spack/spack/pull/8244 and release v2.1.2
This change requires the old automake if you're building the older
release and is relaxed about the automake it requires if you're
building the v2.1.2 release.
Building v2.1.1 and v2.1.2 works on a CentOS 7 system, I don't have
the necessary bit to actually test the resulting binaries.
Here's the commit note from the change that was ultimately merged
upstream.
Fixes#8025
> Tophat was failing to build with automake@1.16.1, it worked with the
> older automake@1.15.1. This commit adds a patch to Tophat's
> src/Makefile.am which cleans up a few things. The result builds
> successfully with both automake@1.15.1 and automake@1.16.1. I have no
> way to check that the resulting builds Do The Right Thing.
>
> It changes two things:
>
> the original Makefile.am had a rule for $(SAMPROG) with no
> actions, and since there was a directory there with a tempting name
> the newer automake was trying to do something with it, but lacked
> the appropriate clues. Since that target is actually made as a side
> effect of making the library (sigh...), it seems to work to just
> give that rule something harmless to do (the Peter Principle
> triumphs again...).
>
> a bunch of the targets need a libtophat.a and libgc.a; the older
> automake was probably able to guess what to do given the list of
> sources but the newer automake apparently won't make the necessary
> assumptions. This patch wires up a simple rule and cleans up the
> appropriate dependencies so that things work.
>
> While it may appear that I'm someone who understands automake, keep in
> mind that I only play such a person on a TV reality show. YMMV.
* Remove extraneous when constraint
Fixes: #8258#8090 altered import behavior so that import spack no longer
provides access to many other Spack modules. This addresses
a case which depended on the prior behavior and was not
updated as part of #8090. This particular import error only
came up when users were setting compiler flags on specs.
See also: #8194
* kokkos: update kokkos spackage to add current host/gpu architectures.
* kokkos: simplify host/gpu architecture selection and make intent of arg population logic more clear.
* kokkos: mollify flake8.
* Make strings and logic more pythonic. Add error for GPU arch without CUDA.
* kokkos: simplify conflicts behaviour. make args population more pythonic.
* kokkos: move gpu values to list for use in variant and conflicts checking.
* kokkos: How fortunate the man with None.
* kokkos: fix gpu_arch conflict loop error. add conflict to guard against +cuda and 2.5.00:develop versions, until kokkos issue #1296 is resolved.
* kokkos: mollify flake8.
* kokkos: add descriptive message to version conflict with +cuda.
