ff23672591
* fixes #967 * Version bump to 0.9.1 - Bugfixes for spack find - 0.9.1 can read specs from current develop. * Don't assume spack is in the path when building docs. * Quick fix for relocation issues. * elf relocation fix: cherry-picked from develop branch (#6889) * Revert "Quick fix for relocation issues." This reverts commit57608a6dc4. * Buildcache: relocate fixes (#6512) * Updated function which checks if a binary file needs relocation. Previously this was incorrectly identifying ELF binaries as symbolic links (so they were being excluded from relocation). Added test to check that ELF binaries are not considered symlinks. * relocate_text was not replacing paths in text files. Added test to check that text files are relocated properly (i.e. paths in the file are converted to the new prefix). * Exclude backup files created by filter_file when installing from binary cache. * Update write_buildinfo_file method signature to distinguish between the spec prefix and the working directory for the binary cache package. * Final changes for v0.11.0 (#6318) * Fix logo link in README.md to point to the develop branch. (#6969) * Compiler flag handlers (#6415) This adds the ability for packages to apply compiler flags in one of three ways: by injecting them into the compiler wrapper calls (the default in this PR and previously the only automated choice); exporting environment variable definitions for variables with corresponding names (e.g. CPPFLAGS=...); providing them as arguments to the build system (e.g. configure). When applying compiler flags using build system arguments, a package must implement the 'flags_to_build_system_args" function. This is provided for CMake and autotools packages, so for packages which subclass those build systems, they need only update their flag handler method specify which compiler flags should be specified as arguments to the build system. Convenience methods are provided to specify that all flags be applied in one of the 3 available ways, so a custom implementation is only required if more than one method of applying compiler flags is needed. This also removes redundant build system definitions from tutorial examples * Fix type issues with setting flag handlers (#6960) The flag_handlers method was being set as a bound method, but when reset in the package.py file it was being set as an unbound method (all python2 issues). This gets the underlying function information, which is the same in either case. The bug was uncovered for parmetis in #6858. This is a partial fix. Included are changes to the parmetis package.py file to make use of flag_handlers. * Bump version to 0.11.1 * Added flags to unit tests + OSX build done once per day (#6988) * Adding flags to codecov reports * OSX builds are triggered once a day * Pull R list_urls from upstream. * travis: removed /usr/local/include/c++ before installing gcc on OSX (#6515) (#7027) "brew install gcc" fails for travis build because of an existing /usr/local/include/c++. This commit removes the offending file as suggested by brew. * Fix gfortran 7 detection (#7017) * Add NameError to exceptions caught from configure_args in module generation (#7173) * Revert "Binary caching: remove symlinks, copy files instead (#9747)" This reverts commit058cf81312. * Make Spack relocate text files in build caches with relative binaries * add the tfel package * fix the tfel package * fix the tfel package * fix the tfel package * Taking Adam J. Steward' remarks into account * fixes trailing white spaces * Update description * Update dependencies following @adamjstewart adices * Style fixes * Style fixes * Add java optional support * add the maintainers attribute (following @alalazo advice), disable interface not selected (following @adamjstewart advice) * flake8 fixes * Fix Cast3M and python-bindings support. Python detection is made compatible with cmake'FindPythonLibs module (at least how it is used in TFEL) * Style fixes * Style fixes * Fix test on python version * Follow @adamjstewart advices: code is much cleaner and readable * Small fix * Small fix * Add comment * Small fix in cmake option * try again (trying to overcome Travis CI unstable build process) * Add support for the MFrontGenericInterfaceSupport project (MGIS) * Style fixes * Package documentation update * Package documentation update * Fix a typo thanks to Andreas Baumbach review * Follow Adam J. Stewart advices * Fix type * bugfix: add back r's for invalid regexes * tutorial basics section: fix gcc install version * version bump: v0.12.1 * bugfix: bring in .travis.yml from develop * Add new TFEL' versions (3.0.4, 3.1.4 and 3.2.1). Add new MGIS version (1.0.1). Fix MGIS dependency * merge with spack:develop * add missing dependency * new versions of and * Fix MGIS url. Fix duplicate variant in TFEL * Fix tfel packaging according to Adam J. Stewart' advices * Fix flake8 warning Co-authored-by: Massimiliano Culpo <massimiliano.culpo@gmail.com> Co-authored-by: Todd Gamblin <tgamblin@llnl.gov> Co-authored-by: Peter Scheibel <scheibel1@llnl.gov> Co-authored-by: Greg Becker <becker33@llnl.gov> Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
Spack
Spack is a multi-platform package manager that builds and installs multiple versions and configurations of software. It works on Linux, macOS, and many supercomputers. Spack is non-destructive: installing a new version of a package does not break existing installations, so many configurations of the same package can coexist.
Spack offers a simple "spec" syntax that allows users to specify versions and configuration options. Package files are written in pure Python, and specs allow package authors to write a single script for many different builds of the same package. With Spack, you can build your software all the ways you want to.
See the Feature Overview for examples and highlights.
To install spack and your first package, make sure you have Python. Then:
$ git clone https://github.com/spack/spack.git
$ cd spack/bin
$ ./spack install zlib
Documentation
Full documentation is available, or
run spack help or spack help --all.
Tutorial
We maintain a hands-on tutorial. It covers basic to advanced usage, packaging, developer features, and large HPC deployments. You can do all of the exercises on your own laptop using a Docker container.
Feel free to use these materials to teach users at your organization about Spack.
Community
Spack is an open source project. Questions, discussion, and contributions are welcome. Contributions can be anything from new packages to bugfixes, documentation, or even new core features.
Resources:
- Slack workspace: spackpm.slack.com. To get an invitation, click here.
- Mailing list: groups.google.com/d/forum/spack
- Twitter: @spackpm. Be sure to
@mentionus!
Contributing
Contributing to Spack is relatively easy. Just send us a
pull request.
When you send your request, make develop the destination branch on the
Spack repository.
Your PR must pass Spack's unit tests and documentation tests, and must be PEP 8 compliant. We enforce these guidelines with Travis CI. To run these tests locally, and for helpful tips on git, see our Contribution Guide.
Spack uses 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.
Code of Conduct
Please note that Spack has a Code of Conduct. By participating in the Spack community, you agree to abide by its rules.
Authors
Many thanks go to Spack's contributors.
Spack was created 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.
License
Spack is distributed under the terms of both the MIT license and the Apache License (Version 2.0). Users may choose either license, at their option.
All new contributions must be made under both the MIT and Apache-2.0 licenses.
See LICENSE-MIT, LICENSE-APACHE, COPYRIGHT, and NOTICE for details.
SPDX-License-Identifier: (Apache-2.0 OR MIT)
LLNL-CODE-647188