Dotkit is being used only at a few sites and has been deprecated on new
machines. This commit removes all the code that provide support for the
generation of dotkit module files.
A new validator named "deprecatedProperties" has been added to the
jsonschema validators. It permits to prompt a warning message or exit
with an error if a property that has been marked as deprecated is
encountered.
* Removed references to dotkit in the docs
* Removed references to dotkit in setup-env-test.sh
* Added a unit test for the 'deprecatedProperties' schema validator
* libint: switch to 2-stage build for 2.6.0+
* libint: add tune and fortran variants
* cp2k: add support for libint >= 2.0
* cp2k: use pkg-config for linking libxc
* github releases are not released versions, but from-source
releases
* they lack the mimification of the JS/CSS components and as
such require node-js and npm, this conflicts with python@3:
* this commit
* drops the from-source dependencies on node-js and npm and
* updates the checksums to the correct sha256 hashes of the
pypi releases. The pypi-tarballs are different
* ZFP: CMake Package
ZFP is primarily build via CMake, which will have all install logic
and configuration files generated.
The 0.5.0 release did not support this yet, so we toss it.
* Patch ADIOS1: ZFP 0.5.1+ support
* ZFP: Expose all CMake variants
fixes#12915closes#12916
Since Spack has support for specific targets it might happen that
software is built for targets that are not exactly the host because
it was either an explicit user request or the compiler being used is
too old to support the host.
Modules for different targets are written into different directories
and by default Spack was adding to MODULEPATH only the directory
corresponding to the current host. This PR modifies this behavior to
add all the directories that are **compatible** with the current host.
* new package: py-python-ldap
* fix dependency types
* improvements
* Update var/spack/repos/builtin/packages/py-python-ldap/package.py
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
* Update var/spack/repos/builtin/packages/py-python-ldap/package.py
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
* add openldap dependency
* go-md2man: disable module-mode
* Update var/spack/repos/builtin/packages/go-md2man/package.py
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
* add singularity 3.4.1
Signed-off-by: ArangoGutierrez <eduardo@sylabs.io>
* revert some changes
Signed-off-by: ArangoGutierrez <eduardo@sylabs.io>
* add maintainers list to pkg singularity
Add @alalazo and me to the Singularity maintainers list
* Update var/spack/repos/builtin/packages/singularity/package.py
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
* Update var/spack/repos/builtin/packages/singularity/package.py
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
* Update var/spack/repos/builtin/packages/singularity/package.py
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
7bcb306 updated setup_environment in the GCC package to examine the
bin/ directory to find alternatively-named instances of CC, but this
failed to account for when GCC was being installed and failed when
it attempted to list the not-yet-existing installation prefix. This
commit updates the logic to skip this search if the bin/ directory
doesn't exist.
* libaio: fixed a condition that checks whether we are running on OS X
* libaio: simplified package by adding an explicit conflict for darwin
* libaio: added information to the docstring
* fio: added version 3.16, added conflict when using libaio, docstring
* lvm2: conflict due to libaio dep, improved docstring, simpler install
* mariadb: conflict due to libaio dep, improved docstring, version 10.4.7
* mariadb: the dependency on libaio is now conditional, removed conflict
* mariadb: fixed a typo in previous commit
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
* libaio: turned into a MakefilePackage
Sometimes when remove_file is called on a link, that link is missing
(perhaps ctrl-C happened halfway through a previous action). As
removing a non-existent file is no problem, this patch changes the
behavior so Spack continues rather than stopping with an error.
Currently you would see
ValueError: /path/to/dir is not a link tree!
and now it continues with a warning.
Unlike the compiler binary name search logic, the `setup_environment` in
GCC's package assumes the compiler names are *exactly* `gcc`, `g++`,
etc. In many external installations (Homebrew, Macports) the
installation includes only *suffixed* versions such as `gcc-9`.
This patch uses the GCC compiler search suffixes to actually locate the
correct filenames for the installed compilers, allowing the
Spack-generated module file to have useful definitions of CC, CXX, etc.
It also allows for the possibility that the user's external installation
of GCC is compiled without Fortran support, in which case the `FC`
environment variables are not defined.
bin/spack now needs to have a "-*- python -*-" line after the shebang, so
that emacs will interpret it as a python file instead of as a shell
script. Add one line to the license check limit to accommodate this.
The Python landscape is going to be changing in 2020, and Python 2 will
be end of life. Spack should *prefer* Python 3 to Python 2 by default,
but we still need to run on systems that only have Python2 available.
This is trickier than it sounds, as on some systems, the `python` command
is `python2`; on others it's `python3`, and RHEL8 doesn't even have the
`python` command. Instead, it makes you choose `python3` or
`python2`. You can thus no longer make a simple shebang to handle all the
cases.
This commit makes the `spack` script bilingual. It is still valid
Python, but its shebang is `#!/bin/sh`, and it has a tiny bit of shell
code at the beginning to pick the right python and execute itself with
what it finds.
This has a lot of advantages. I think this will help ensure that Spack
works well in Python3 -- there are cases where we've missed things
because Python2 is still the default `python` on most systems. Also,
with this change, you do not lose the ability to execute the `spack`
script directly with a python interpreter. This is useful for forcing
your own version of python, running coverage tools, and running profiling
tools. i.e., these will not break with this change:
```console
$ python2 $(which spack) <args>
$ coverage run $(which spack) <args>
$ pyinstrument $(which spack) <args>
```
These would not work if we split `spack` into a python file and a shell
script (see #11783). So, this gives us the best of both worlds. We get
to control our interpreter *and* remain a mostly pure python executable.
