* This fixes a bug in concretization. Before the recent change to the
algorithm, the intent was that the @develop version, although
"greater" than numberic versions, is never preferred BY DEFAULT over
numeric versions.
To test this... suppose you have a package with no `preferred=True` in
it, and nothing in `packages.yaml`, but with a `develop` version. For
the sake of this example, I've hacked my `python/package.py` to work
this way.
Without bugfix (WRONG: user should never get develop by default):
```
python@develop%clang@7.3.0-apple~tk~ucs4 arch=darwin-elcapitan-x86_64
...
```
With bugfix (RIGHT: largest numeric version selected):
```
python@3.5.2%clang@7.3.0-apple~tk~ucs4 arch=darwin-elcapitan-x86_64
...
```
* Documented version selection in concretization algo.
* Fix typos
* flake8
* Fix various documentation bugs
* Keep long option names, but don't include in Command Index
* Use long option name
* Explicitly designate sections to be listed in the Command Index
* Consistent menu bar titles
Input/output/error streams not directed to None or 'str' were not being closed
because `close()` method was being called on the argument value (a string type)
instead of the open file descriptor object.
* Fix bug in handling of precedence of preferred=True vs. versions given in packages.yaml (#1556)
* Standardized comparison of versions: numeric versions are always greater than non-numeric versions; and non-numeric versions are sorted alphabetically.
This is
a) simple
b) ensures that non-numeric versions (such as 'develop') in package.py are not chosen ahead of numeric versions, when nothing is specified in packages.yaml
Fixes Issue #1557
* Removed debugging output
* Fix variable shadowing bug
* Ensure develop < numeric version.
* Bug fix.
* Passes all unit tests in versions.py
* flake8 fixes
* flake8 fixes
* Changed type test to be more correct.
See http://stackoverflow.com/questions/8203336/difference-between-int-and-numbers-integral-in-python
This closes#1757 which provides an example of a url scheme where the
version appears after the extension. Instead of extending the parsing
logic to handle this case, this commit allows the user to specify
their extension type. This helps Spack choose the appropriate
decompressor and mirror archive filename.
* Transferred pending changes from efischer/develop
* 1. Rewrite of "Getting Started": everything you need to set up Spack, even on old/ornery systems. This is not a reference manual section; items covered here are covered more systematically elsewhere in the manual. Some sections were moved here from elsewhere.
2. Beginning to write three methods of application developer support. Two methods were moved from elsewhere.
* Edits...
* Moved sections in preparation for additional text to be added from old efischer/docs branch.
* Moved 2 more sections.
* Avoid accid
* Applied proofreading edits from @adamjstewart
* Fixed non-standard section characters.
* Moved section on profiling to the developer's guide.
* Still working on Spack workflows...
* Finished draft of packaging_guide.rst
* Renamed sample projects.
* Updates to docstrings
* Added documentation to resolve#638 (content taken from #846)
* Added section on resolving inconsistent run dependencies. Addresses #645
* Showed how to build Python extensions only compatible with certain versions of Python.
* Added examples of getting the right behavior from depends_on(). See #1035
* Added section on Intel compilers and their GCC masquerading feature. Addresses #638, #1687.
* Fixed formatting
* Added fixes to filesystem views. Added a caveats section to ``spack setup``.
* Updated section on Intel compiler configuration because compiler flags currently do not work (see #1687)
* Defined trusted downloads, and updated text based on them. (See #1696)
* Added workflow to deal with buggy upstream software. See #1683
* Added proper separation between Spack Docs vs. Reference Manual
* Renamed spack_workflows to workflows. Resolves a conflict with the .gitignore file.
* Removed repeated section.
* Created new "Vendor Specific Compiler Configuration" section and organized existing Intel section into it. Added new PGI and NAG sections; but they need to be expanded / rewritten based on the existing text plus research through Spack issues on GitHub.
* Fixed text on `spack load --dependencies` to conform to reality. See #1662
* Added patching as option for upstream bugfixes.
* Added section on using licensed compilers.
* Added section on non-downloadable tarballs.
* Wrote sections on NAG and PGI. Arranged compilers in alphabetical order.
* Fix indent.
* Fixed typos.
* Clarified dependency types.
* Applied edits from Adam J. Stewart. Spellchecked workflows and getting_started.
* Removed spurious header
* Fixed Sphinx errors
* Fixed erroneous symbol in docstring.
* Fix many typos and formatting problems.
* Spacing changes
* Added section on fixing Git problems. See #1779
* Fixed signature of install() method.
* Addressed system packages in greater detail. See #1794#1795
* Fixed typos
* Fixed quotes
* Duplicate section on Spack profiling removed from configuration.rst. It had earlier been moved to developer_guide.rst, where it fits better.
* Minor edits
- Tweak supported platform language.
- Various small changes to the new getting started guide.
* Fixed bug with quotes.
- Fixed up dependency management so that:
- build deps go in PATH and -I
- link deps go in -L args
- only *immediate* link deps are RPATH'd
The latter reduces the number of libraries that need to be added to
DT_NEEDED / LC_RPATH. This removes redundant RPATHs to transitive
dependencies.
* Fixes#1720: spack reindex fails with invalid ref count.
- Database graph wasn't being built properly; dependencies were set up
incorrectly in the nodes that ended up in the graph on reindex.
- Reworked _add to increment ref count properly and to always build
bottom-up to make the logic simpler to understand.
* Add checks to ensure DB is a valid merkle tree.
- Distinguish between static (package) and dynamic (spec) graphs.
- static graphs ignore conditions and multiple instances (hashes) and
plot raw dependencies among packages.
- dynamic graphs include information from particular specs (instances of
packages) and can have multiple instances with hashes.
- Allow graphing all packages in the install DB.
- useful for debugging.
* Perform shebang fix for all files
* Fix sbang for perl scripts
Otherwise perl would look at the #! line and call sbang again, resulting
in an infinite loop.
* Turned <provider>_libs into an iterable
Modifications :
- added class LibraryList + unit tests
- added convenience functions `find_libraries` and `dedupe`
- modifed non Intel blas/lapack providers
- modified packages using blas_shared_libs and similar functions
* atlas : added pthread variant
* intel packages : added lapack_libs and blas_libs
* find_library_path : removed unused function
* PR review : fixed last issues
* LibraryList : added test on __add__ return type
* LibraryList : added __radd__ fixed unit tests
fix : failing unit tests due to missing `self`
* cp2k and dependecies : fixed blas-lapack related statements in package.py
* Fixed bug propagating --dirty flag to sub-installs.
* Fix syntax error
* Allow --dirty flag to be set with SPACK_DIRTY env var.
* Added dirty flag to `spack diy` and `spack setup`, as is currently in `spack install`
* flake8
Includes :
- treatment of a generic hierarchy (i.e. lapack + mpi + compiler)
- possibility to specify which compilers are to be considered Core
- correct treatment of the 'family' directive
- unit tests for most new features
When re-using previously downloaded tarballs, spack copies from
`var/spack/stage/PACKAGE-VERSION-HASH/downloaded_file` to
`var/spack/cache/PACKAGE/downloaded_file`. This fails if the source is owned by
a different user (`shutil.copy` tries to retain all meta data including file
ownership). Change to a non-meta-data copy function (`shutil.copyfile`).
This closes#1308, where fetching a non-expanded resource from a mirror
will cause an error.
This also ensures that when a URL resource is fetched from a mirror,
that it will be named as though it were retrieved from the original
URL. This is particularly useful for non-expanded resources since it
ensures that the resource name is consistent for the installation
(this is less important for expanded resources because the build takes
place inside the expanded resource).
