* Better cxx11/14 flags for GNU/Clang/Intel
- GCC 4.8 only supports -std=c++1y for C++14
- Use CMake's rules for AppleClang to set cxx11 and cxx14 flags based on
Apple Xcode/LLVM version
- Use CMake's rules for Intel to add support for cxx14 flags based on
Intel version.
* Add cxx17_flag property
Implement property in compiler for c++17 as per those for c++11/14.
Add concrete support for GNU/Clang:
- Return -std=c++1z for GCC 5 and above per GCC documentation
- Return -std=c++1z for Clang 3.5 and above per Clang documentation
- Return -std=c++1z for Apple LLVM 6.1 and above per CMake's rules
* Added support for xSDKTrilinos package
* Updated xsdktrilinos/package.py for PR review
* Added trilinos version # reqs to xsdktrilinos
* xsdktrilinos now uses CMakePackage
* Cleaned up xsdktrilinos/package.py
* Removed unused cxxflags from xsdktrilinos
* Removed unused sys import from xsdktrilinos
* Update `spack setup` and `spack graph` to be consistent with c557e765 and 9347f869. Fixes#2316.
* Added another "fix" necessary to make `spack setup` work.
* Added another "fix" necessary to make `spack setup` work. (reverted from commit 7f0d3ecb38c97ec00491d7cd66b4266e3018b1ca)
* Add documentation for repositories and namespaces.
* Update and extend repository documentation per review.
- Also add `-N` argument for `spack spec`
The advanced [Uninstalling Packages](spack.readthedocs.io/en/latest/tutorial_sc16_spack_basics.html#uninstalling-packages) via hash has a couple missing `.. code-block:: console` directives ;)
I have no idea what branch to direct this to though...
* clang: do xcode mockup iff requested by a package
* add a note
* add pkg to setup_custom_environment() and decide whether or not to use mockup XCode there based on the package
Supports installing both a "known version" of PETSc/PFlotran that works and
the develop/master branches of both packages
Funded-by: IDEAS
Project: IDEAS/xSDK
Time: 4 hour
* update flux dependencies and package
* refinements from @adamjstewart
* fix flux document generation
The docbook-xsl package has been added, and correctly configures catalog
files to generate documentation correctly with asciidoc.
* Make targets an attribute of compilers, similar to OS. Allows users to use `spack compiler find` to add compilers for the same platform/os but different targets when spack is installed on a file system mounted on machines with different targets.
* Changed get_compilers() method to treat old compilers with no target as target='any'
* flake8 changes
* Address change requests for comments/code clarity
* Update emacs: current release, use our x11 bits
Add checksum for 25.1 release.
Rework the X support:
- use Spack's X11 bits
- add ability to specify an X toolkit (gtk or athena, default is gtk).
- change toolkit names to align with Emacs' configure usage.
* PEP8 cleanups.
* glib dependency should not be type=build
I'd like to blame that on a typo, but it's a few too many characters
for that to be viable. I'm not sure what I was thinking.
* Pass X variant down: emacs->pango->cairo
* X variants default to False, warn on bad toolkit
Change the X variants for emacs, pango and cairo to default to False.
Check that the toolkit is a valid choice and give a reasonable error if
not.
* Fix flake8 issue, reword warning text
* gtkplus needs to use +X variant for pango to work
In order for a useful variant of pango to be built into the spec I
needed to make the dependency on gtkplus explicitly specify it's X
variant. The X variant is the default, but that wasn't enough to make
it happy. Since it's happiness is the most imporant thing in the
world, this change! :)
Fixes#2306
Any dependency explicitly mentioned in a spec string ended up with the
build and link deptypes unconditionally. This fixes dependency
resolution to ensure that packages which are mentioned in the spec
string have their deptypes determined by the dependency information
in the package.py files. For example if a package has cmake as a build
dependency, and cmake is mentioned as a dependency in the spec string
for the package, then it ends up with just the build deptype.
Packages built targeting a backend may depend on packages like cmake
which can be built against the frontend. With this commit, any build
dependency or child of a build dependency will target the frontend by
default. In compiler concretization when packages copy compilers from
nearby packages, build dependencies use compiler information from
other build dependencies, and link dependencies avoid using compiler
information from build dependencies.
yaml-cpp has a boost dependency, and according to [yaml-cpp
page](https://github.com/jbeder/yaml-cpp):
yaml-cpp 0.5.3 has been released! This is a bug fix release. It also
will be the last release that uses Boost; futures releases will require
C++11 instead.
See #2059 for background.
I'm unable to install `lmod` because lua-luafilesystem fails.
The luarocks install bits attempt to do a shallow clone of the luafilesystem
sources and the default git on my CentOS 7 test box (`git version 1.8.3.1`)
fails.
This adds a build dependency that ensures that a relatively modern git is
available.
* Update texlive digest value
While the discussion in #2494 progresses, this changes fixes the digest
values so that builds succeeed.
* Add warning that texlive is not repeatably installable
