* spectrum-mpi: Add new package file for external package
IBM Spectrum MPI is a commercial implementation of MPI based on
OpenMPI. It is usually install in /opt/ibm/spectrum_mpi.
Users need to add the Spectrum MPI package in their packages.yaml
file as follows:
packages:
spectrum-mpi:
version: ['10.1.0.2']
paths:
spectrum-mpi@10.1.0.2: /opt/ibm/spectrum_mpi/
buildable: False
all:
providers:
mpi: [spectrum-mpi@10.1.0.2]
* spectrum-mpi: Added license files and removed the versions
No need for versions as the package is external.
* spectrum-mpi: Remove extraneous defines
Keep only the defines that other MPI implementation define in their
package file:
self.spec.mpicc
self.spec.mpicxx
self.spec.mpif77
self.spec.mpifc
- Fix format printing to match command line for hashes and full name formats
- Update spack graph to use new format
- Changed format string signifier for hashes from `$#` to `$/`
Update the go package to v1.7.5.
- This release no longer needs the time-test patch (it's been merged upstream).
- This release still seems to need the cgo-testcshared patch.
- Also add a comment about environment set up that I need to build it successfully on a very large server.
Tested on CentOS 7.
Modules generated by the module creation machinery currently print out
a notice that warnts the user that things are being autoloaded. In
some situations those warnings are problematic. See #2754 for
discussion.
This is a first cut at optionally disabling the warning messages:
- adds a helper tothe EnvModule base class that encapsulates the
config file variable;
- adds a method to the base class that provides a default (empty)
code fragment for generating a warning message;
- passes the warning fragment into the bit that formats the autoload
string;
- adds specialized autload_warner() methods in the tcl and lmod
subclasses;; and finally
- touches up the autoload_format strings in the specialized classes.
The repository used by the texlive installer defaults to a redirector
that sends one off to various URLs depending on <fill in the blank>.
This is problematic because all of the mirrors do not update in
synchrony and bad tarballs often hang around for a while.
This leads to problems that are particularly hard to diagnose because
you're likely to end up using a different repo the next time around.
This commit constraints the package to a particular, mainstream,
repository. It's not fast, but it's consistent and usually correct.
It also updates the installer digest, because no day is complete
without updating it at least (sigh) once.
Add the ability to the modules generation process to blacklist
packages that were installed implicitly. One can still whitelist
modules that were installed implicitly.
This changes adds a `blacklist_implicts` boolean as a peer to the
`whitelist` and `blacklist` arrays, e.g.:
```
modules:
enable::
- lmod
lmod:
whitelist:
- 'lua'
- 'py-setuptools'
blacklist:
- '%gcc@4.8.3'
blacklist_implicits: True
```
It adds a small helper in `spec.py` and then touches up the package
filtering code in `modules.py`.
* Different versions of cmake need diff vers of openssl. See Issue https://github.com/LLNL/spack/issues/2990 for background.
Versions of cmake through 3.6.9 seem to need OpenSSL up to 1.0.99. Later
versions can use the current release (thanks to @citibeth for
[digging up details](https://cmake.org/pipermail/cmake/2016-November/064631.html)).
@davydden suggested this change.
Without it I *am not* able to build `cmake@3.6.1` on CentOS 7 and I *am*
able to build `cmake@3.7.2`.
Tested with `cmake@3.7.2` and `cmake@3.6.1` on CentOS 7.
With this change I am able to build both `cmake@3.6.1` and `cmake@3.7.2`
on CentOS 7.
There was a new release of Ant (1.9.8) which led to the v1.9.7
tarball disappearing.
This changes the URL to Ant's archive dir, which seems to contain
*everything* including the two current releases (1.9.8 and 1.10.0)
It adds a digest for 1.9.8.
It adds and comments out a digest for 1.10.0 (which requires Java 8),
as I have not tested it.
We just released 2.0.2 yesterday, so add in that release for
spack. Don't need the PMI patch for this release.
Signed-off-by: Howard Pritchard <howardp@lanl.gov>
cran.r-project.org runs on a single old-school server in Austria
and could potentially be overloaded if "everyone" used it.
cloud.r-project.org is a cloud-based repository that "automatic redirection to servers worldwide [...]", cf. https://cran.r-project.org/mirrors.html.
I assume, that cloud.* can be scale up as needed. Out of the official CRAN mirror, this should be the safest one to pick if a static CRAN mirror is needed.
* Replace `spack urls` and `spack url-parse` with `spack url`
* Allow spack url list to only list incorrect parsings
* Add spack url test reporting
* Add unit tests for new URL commands
* Add several new R packages
* Add a few more R packages
* Update more versions
* Convert Package to RPackage
* Add a few more packages
* Add missing dependencies
* AutotoolsPackage: added configure_directory to permit build out of source. The configure script executable is now invoked with an absolute path. Modified a few packages accordingly.
* build_systems: functions returning directories are now properties
* build_systems: fixed issues with tcl and tk
* AutotoolsPackage: reworked recipe for autoreconf
