90bb855ffa
not change the behavior for existing packages that subclass from
spack.Package.
If a package subclasses spack.StagedPackage instead of spack.Package,
the install() phase (run inside a forked process) is now separated
into sub-stages:
a) spconfig: Generate a script spconfig.py that will configure the
package (eg by running CMake or ./configure) This is for use if
the user wishes to build externally from Spack. Therefore, the
Spack compiler wrappers are NOT used here. Currently, that
means that RPATH support is up to the user.
b) configure: Configure the project (eg: runs configure, CMake,
etc). This will configure it for use within Spack, using the
Spack wrapper.
c) build: eg: "make"
d) install: eg: "install"
If one chooses to use StagedPackage instead of Package, then one must
implement each of the install sub-stages as a separate method.
StagedPackage.install() then calls each of the sub-stages as
appropriate.
StagedPackage can be configured to only run certain sub-stages. This
is done by setting the optional kwarg install_phases when calling
do_install(). Setting install_phases() ONLY has an effect on
StagedPackage, not on any existing packages. By default,
install_phases is set to make StagedPackage run the same stages that
are normally run for any package: configure, build, install (and NOT
spconfig).
The ability for Spack to run stages selectively for StagedPackage
instances will enable new functionality. For example, explicit
CMake/Autotools helpers that allow Spack to help configure a user's
project without fetching, building or installing it.
-------------
One implementation of StagedPackage is provided, CMakePackage. This
has the following advantage for CMake-based projects over using the
standard Package class:
a) By separating out the phases, it enables future new functionality
for packages that use it.
b) It provides an implementation of intall_spconfig(), which will
help users configure their CMake-based projects.
CMakePackage expects users to implement configure_args() and
configure_env(). These methods provide the package-specific arguments
and environment needed to properly configure the package. They are
placed in separated functions because they are used in both the
spconfig and configure stages.
TODO:
1. Generate spconfig.py scripts that are more readable. This allows
the users to understand how their project is configured.
2. Provide a practical way for the user to ACCESS the spconfig stage
without building the project through Spack.
3. The CMAKE_TRANSITIVE_INCLUDE_PATH stuff needs to be reworked; it
should be considered provisional for now.
4. User of Autotools might wish to make a similar ConfigurePackage
subclass of StagedPackage.
---------------
One package using CMakePackage is introduced. See ibmisc/package.py.
|
||
|---|---|---|
| bin | ||
| etc/spack | ||
| lib/spack | ||
| share/spack | ||
| var/spack/repos | ||
| .gitignore | ||
| .mailmap | ||
| .travis.yml | ||
| LICENSE | ||
| README.md | ||
Spack is a package management tool designed to support multiple versions and configurations of software on a wide variety of platforms and environments. It was designed for large supercomputing centers, where many users and application teams share common installations of software on clusters with exotic architectures, using libraries that do not have a standard ABI. Spack is non-destructive: installing a new version does not break existing installations, so many configurations can coexist on the same system.
Most importantly, Spack is simple. It offers a simple spec syntax so that users can specify versions and configuration options concisely. Spack is also simple for package authors: package files are written in pure Python, and specs allow package authors to write a single build script for many different builds of the same package.
See the Feature Overview for examples and highlights.
To install spack and install your first package:
$ git clone https://github.com/llnl/spack.git
$ cd spack/bin
$ ./spack install libelf
Documentation
Full documentation for Spack is the first place to look.
See also:
- Technical paper and slides on Spack's design and implementation.
- Short presentation from the Getting Scientific Software Installed BOF session at Supercomputing 2015.
Get Involved!
Spack is an open source project. Questions, discussion, and contributions are welcome. Contributions can be anything from new packages to bugfixes, or even new core features.
Mailing list
If you are interested in contributing to spack, the first step is to join the mailing list. We're using a Google Group for this, and you can join it here:
Contributions
At the moment, contributing to Spack is relatively simple. Just send us
a pull request.
When you send your request, make develop the destination branch.
Spack is using a rough approximation of the Git
Flow
branching model. The develop branch contains the latest
contributions, and master is always tagged and points to the
latest stable release.
Authors
Many thanks go to Spack's contributors.
Spack was originally written by Todd Gamblin, tgamblin@llnl.gov.
Citing Spack
If you are referencing Spack in a publication, please cite the following paper:
- Todd Gamblin, Matthew P. LeGendre, Michael R. Collette, Gregory L. Lee, Adam Moody, Bronis R. de Supinski, and W. Scott Futral. The Spack Package Manager: Bringing Order to HPC Software Chaos. In Supercomputing 2015 (SC’15), Austin, Texas, November 15-20 2015. LLNL-CONF-669890.
Release
Spack is released under an LGPL license. For more details see the LICENSE file.
LLNL-CODE-647188