Modifications:
- added support for multi-valued variants
- refactored code related to variants into variant.py
- added new generic features to AutotoolsPackage that leverage multi-valued variants
- modified openmpi to use new features
- added unit tests for the new semantics
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
* Make dia build w/ Spack's X bits (and misc)
X related
- need to depend on the +X variant of gtkplus
- need to depend on freetype
misc
- fix path to tarball
* Make freetype a "build" dependency
* Freetype is not just a build dep
* ncurses package will build ncurses and ncursesw
* Added libs property to ncurses, added fix for hstr
* flake8 is a harsh mistress
* make libs() more robust
* atop depends on ncurses
* fish depends on ncurses
* libtermkey and nano depend on ncurses
* Adjust url spacing
* Added a patch to the openblas package to change the openmp flag for
icc to qopenmp.
* Fixed a linking problem where when using Intel compilers, it was still
pulling in -lgfortran
* depend on readline, remove hardcoded -ltermcap
Bowtie should use Spack's readline and not explicitly depend on the
system termcap (which, on CentOS, leads to linking against the
system's tinfo library).
* Add depends_on('zlib')
* Add conflict with gcc@6:
Build seems to have trouble with 6's migration to -std=gnu++14.
* Dia requires libxml2.
* Clean up dependencies for Dia (and add X11 deps).
+ Remove dependencies on cairo and libpng. The will be satisfied via gtkplus.
+ Add dependencies on X11 libraries: libsm, libuuid, libxinerama, libxrender.
+ From a dependency diagram, it doesn't appear that we need libxml2 since this
dependency should be come in through cairo (via gtkplus). However, Dia will
not build without it.
* Hackery to get gtkplus to build
PR #3077 broke gtkplus by introducing gobject-introspection.
This big hack makes things work. It has problems.
1. Rather than deal with the nasty sbang fooey in the
g-ir-tool-template.in derived scripts, it just adds a python
dependency to each package that runs one of the scripts. This lets
the `/usr/bin/env python` sbang do the right thing.
2. It stuffs a several directories on to the XDG_DATA_DIRS environment
variable, which is used for (among other things) locating the .gir
files.
3. It avoids building the gtkplus demos because I can't make the bit
that calls `gdk-pixbuf-csource` work. It doesn't think that it can
load `.png` files and all of the google hits I found suggest a bad
`loader.cache` file. The file's fine and I can strace the command
and watch it read it in... Many, many hours wasted here.
In spite of the demo failing, the tests pass and an emacs built
with this lib seems to work.
* Fix sbang so everyone needn't depend_on python
Rather than have every package that
`depends_on('gobject-introspection')` also need to
`depend_on('python')`, this commit fixes the
scripts (e.g. `g-ir-scanner`).
The interesting bit is in the gobject-introspection package. There is
a beefy comment there that is included below.
The commit also removes the now un-necessary dependencies from various
packages.
I have two reservations about this commit:
1. How portable is the "insertion" sed command? I'm particularly
worried that some sed's might need the line to insert to be on a
different line, which I can't imagine how to cram into the
Makefile.in.
The solution I see to this is rather than extending the existing
sed command in the Makefile I could shim in another line in the
rule and e.g. call a bit of Perl (or Python, I suppose) which would
end up being much neater.
2. As written it always uses Spack's `.../bin/sbang`, which might or
might not be a good idea.
If I use "the solution" from number 1 above, then I can check the
line length before I munge it. Otherwise???
---
This package creates several scripts from |
toosl/g-ir-tool-template.in. In their original form these |
scripts end up with a sbang line like |
|
`#!/usr/bin/env /path/to/spack/python`. |
|
These scripts are generated and then used as part of the build |
(other packages also use the scripts after they've been |
installed). |
|
The path to the spack python can become too long. Because these |
tools are used as part of the build, the normal hook that fixes |
this problem can't help us. |
This package fixes the problem in two steps: |
- it rewrites the g-ir-tool-template so that its sbang line |
refers directly to spack's python (filter_file step below); and |
- it patches the Makefile.in so that the generated Makefile has an |
extra sed expression in its TOOL_SUBSTITUTION that results in |
an `#!/bin/bash /path/to/spack/bin/sbang` unconditionally being |
inserted into the scripts as they're generated. |
* Cairo needs python when it's +X
Cairo needs to depend_on python when it's +X. I think it's an
indirect requirement that's coming in via libxcb).
* Flake8 cleanup
* Make cairo's dep on python be type=build
This seems to be the right thing and seems to produce a result
that works (I can build gtk+ and then emacs+X on top of it).
* ghostscript: add version 9.21 and handle new URL format
* ghostscript: add url of latest version to fix `spack versions`
* ghostscript: use github for all versions our package provides (>= 9.18)
* perl: provide +gdbm variant for use when system dbm is missing or buggy
* perl: remove gdbm variant; always depends on gdbm
* perl: pass gdbm paths as Configure arguments
The blast+ configure script supports building
--with-{python,perl}=path and --without-{python,perl}.
This commit makes the use of those two languages configurable via
variants and adds dependencies and explicit --with-... or
--without-... flags to configure.
Python was a non-optional dependency, now it is a variant that
defaults to `True`.
Perl was not previously an explicit dependency but the configure
script was likely to discover one on your system (`/usr/bin/perl`).
It is now a variant that defaults to `True`.
I am unable to accurately determine what these flags to the configure
script enable. My users are frustrated by the dependency on Python in
particular because it constrains the other modules that they can have
loaded for new discernible benefit.
* xSDK: a bundle/meta package that simple installs a series of packages with suitable specs
This is based on struggles with previous attempts at such a bundler
Funded-by: IDEAS
Project: IDEAS/xSDK
Time: 12 hours
* PETSc needs c++11 when built with Trilinos
* Added alquimia package
* remove direct setting of cpp in petsc/package.py since it doesn't work on some systems.
Funded-by: IDEAS
Project: IDEAS/xSDK
Time: .3 hours
Reported-by: Mark A. Berrill <berrillma@ornl.gov>
* provide the MPI compilers to PETSc configure with --with-cc etc instead of --with-mpi-dir
Funded-by: IDEAS
Project: IDEAS/xSDK
* Spack bug fix issue #3144
String could contain /n which resulting in spack generating warning message to stderr on each
use of compiler which configure interpreted as failing compiler
Thanks-to: Mark A. Berrill <berrillma@ornl.gov>
* Fixed alquimia package
Alquimia expects PETSC_DIR and PETSC_ARCH to be defined, and
refuses to install if they are not. Spack does not define PETSC_
ARCH, so Alquimia will not install. This patch does two things
to fix the alquimia build:
1. A patch has been added to remove the dependency on PETSC_ARCH.
2. Alquimia currently depends on old versions of PETSc and pflotran.
@ghammond86 updated the alquimia interfaces to use more recent
versions, but his patch is still sitting in an alquimia pull
request. As a result, the spack installer now uses his fork
of alquimia. This is a temporary fix until his pull request is
accepted.
* Need to pass to Alquimia the MPI compilers, not the raw compilers
Otherwise the PETSc tests do not produce executables that can run because they are not
linked against MPI libraries
Funded-by: IDEAS
Project: IDEAS/xSDK
Time: .5 hours
* Add alquimia to xSDK build
Funded-by: IDEAS
Project: IDEAS/xSDK
* Fix flake8 errors for xsdk packages
* Add xsdk support for xsdk version xsdk-0.2.0
Note that currently it is just dummy code, but will eventually use
a xsdk-0.2.0 tag for each package it installs.
Funded-by: IDEAS
Project: IDEAS/xSDK
Time: .7 hours
* Do not build Mumps by default for PETSc since it is not portable, for example to Cray
Allow alquimia to accept PETSc even if the PETSc test executable cannot run since this is a problem on Cray.
Reported-by: Alicia Marie Klinvex <amklinv@sandia.gov>
* Add xsdk-0.2.0-rc1 tag for xsdk-0.2.0 installs
* Switch alquimia download site back to standard location
since they have incorporated Glenn Hammond's fixes
Also it no longer needs the patch to the Alquimia cmake
Funded-by: IDEAS
Project: IDEAS/xSDK
Reported-by: Sergi Molins Rafa <smolins@lbl.gov>
* update hypre to use the latest release candidate for xsdk 0.2.0
Funded-by: IDEAS
Project: IDEAS/xSDK
Reported-by: Ulrike Meier Yang <yang11@llnl.gov>
* Re-added patch to alquimia
The patch was out of date and has been updated accordingly.
* Added Tpetra-free option to Trilinos
The Tpetra stack takes forever to build and is not used by any of the
IDEAS teams, so there should be an option to disable it. I have added
this option and updated the xSDK accordingly. I also disabled
xSDKTrilinos in the xSDK, since none of the apps teams currently use it,
and it's largely Tpetra-based.
* Removed alquimia patch from develop version
The patch has been incorporated into alquimia and is no longer
necessary for the develop version. The tagged version has not
been updated accordingly and still needs the patch for now.
(When the tagged version gets updated, the patch does need to be
removed from spack altogether, or it will break the build.)
* Removed patch from alquimia
It has been incorporated into alquimia, both the develop and
rc2 tagged versions. The 0.2.0 version of alquimia has been updated
to tag rc2 rather than rc1.
* update xsdk-0.2.0 to depend on PETSc xsdk-0.2.0-rc2 which fixes for Apple xcode 8.3
Commit-type: bug-fix
Funded-by: IDEAS
Project: IDEAS/xSDK
* import sys got lost in merge with develop
* Update xsdk packages to use xsdk-0.2.0 tag
Commit-type: feature
Funded-by: IDEAS
Project: ECP
* Fixes for Flake8
note, had to ignore some long lines due to a single string
* simple improvements to XDK packages as suggested by Spack pull request reviewers
Commit-type: style-fix
Funded-by: IDEAS
Project: xSDK
* Removed unneeded : after develop as requested by Denis Davydov in pull request review
Commit-type: style-fix
Funded-by: IDEAS
Project: xSDK
Thanks-to: Denis Davydov
* Removed change that may not be needed due to updates in PETSc spack file such as using mpicc etc directly
Commit-type: bug-fix
Funded-by: IDEAS
Project: xSDK
Thanks-to: Adam J. Stewart
* Do not turn on xSDKTrilinos for xSDK builds since it requires tpetra
Commit-type: bug-fix
Funded-by: IDEAS
Project: xSDK
* comment why MUMPS is disabled by default for PETSc so that others won't try to enable it when modifying petsc package next time
Commit-type: documentation
Funded-by: IDEAS
Project: xSDK
Thanks-to: Denis Davydov
* Properly ignore flake8 F811 redefinition errors
* Add unit tests for flake8 command
* Allow spack flake8 to work on systems with older git
* Skip flake8 unit tests for Python 2.6 and 3.3
* Added a package for the MDAnalysis toolkit.
* Added the hash for the 1.0 release of caffe and put in a conflict
statemet indicating that protobuf requires a c++11 compiler.
* Changed minimum version number.
* Tweaked the minimum version number.
* Fixed flake8 error.
* grib-api: add version 1.21.0
* libemos: add version 4.4.7 and allow choice of eccodes or grib-api
* magics: add version 2.32.0
* libemos: add description for eccodes variant
* eccodes: new package for encoding and decoding meteorological data
* eccodes: remove line breaks from package docstring
* eccodes: simplify names of variants
* eccodes: give a description for each variant
* eccodes: use succinct code for cmake_args
* eccodes: found extra dependency for python variant
* eccodes: add URL for a list of available releases
- py-setuptools is required by py-yt for importing yt in jupyter notebooks.
- add two dependencies needed for python 2.7
- add the py-subprocess32 package
- Spack doesn't need eggs -- it manages its own directories
- Simplify install layout and reduce sys.path searches by installing all
packages flat (eggs are deprecated for wheels, and this is also what
wheels do).
- We now supply the --single-version-externally-managed argument to
`setup.py install` for setuptools packages and setuptools.
- modify packages to only use setuptools args if setuptools is an
immediate dependency
- Remove setuptools from packages that do not need it.
- Some packages use setuptools *only* when certain args (likeb
'develop' or 'bdist') are supplied to setup.py, and they specifically
do not use setuptools for installation.
- Spack never calls setup.py this way, so just removing the setuptools
dependency works for these packages.
* Checksum code wasn't opening binary files as binary.
- Fixes Python 3 issue where files are opened as unicode text by default,
and decoding fails for binary blobs.
* Simplify fetch test parametrization.
* - add tests for URL fetching and checksumming.
- fix coverage on interface functions in FetchStrategy superclass
- add some extra crypto tests.
* Fix for llvm 4.0.0 on centos
This addresses https://github.com/LLNL/spack/issues/3791
* Only enable this option if on linux
* Change condition to satisfy standard
* Package install remove prior unfinished installs
Depending on how spack is terminated in the middle of building a
package it may leave a partially installed package in the install
prefix. Originally Spack treated the package as being installed if
the prefix was present, in which case the user would have to
manually remove the installation prefix before restarting an
install. This commit adds a more thorough check to ensure that a
package is actually installed. If the installation prefix is present
but Spack determines that the install did not complete, it removes
the installation prefix and starts a new install; if the user has
enabled --keep-prefix, then Spack reverts to its old behavior.
* Added test for partial install handling
* Added test for restoring DB
* Style fixes
* Restoring 2.6 compatibility
* Relocated repair logic to separate function
* If --keep-prefix is set, package installs will continue an install from an existing prefix if one is present
* check metadata consistency when continuing partial install
* Added --force option to make spack reinstall a package (and all dependencies) from scratch
* Updated bash completion; removed '-f' shorthand for '--force' for install command
* dont use multiple write modes for completion file
* Add tests to mercurial package
* Add support for --insecure with mercurial fetching
* Install man pages and tab-completion scripts
* Add tests and latest version for all deps
* Flake8 fix
* Use certifi module to find CA certificate
* Flake8 fix
* Unset PYTHONPATH when running hg
* svn_fetch should use to svn-test, not hg-test
* Drop Python 3 support in Mercurial
Python 3 support is a work in progress and isn't currently
recommended:
https://www.mercurial-scm.org/wiki/SupportedPythonVersions
* Test both secure and insecure hg fetching
* Test both secure and insecure git and svn fetching
* Initial add of flac
* Initial add of id3lib
* Initial add of the opus codec
* Initial add of sox audio processing tools
* Cleanup spec files to be inline with current standard
* Fix pep8 compliance
* Remove un-needed configuration
* ncl: add depends_on statements for bison, flex and libiconv
* ncl: depends on flex for building and linking
* ncl: links with -ll, so requires flex with variant '+lex'
* ncl: depends on szip; external hdf5 may not provide it
* Disable parallel builds
The install step creates a bunch of links to the vim binary, e.g.
`view`. When run with -j greater than 1 there are silent failures.
Running w/out parallelism seems to fix it.
* Only constrain the install phase to be -j 1
Thanks @adamjstewart!
* Add package for nginx@1.12.0
Includes support for:
- zlib
- pcre (and pcre-jit)
- openssl (https support)
Built and basics tested on CentOS 7. I haven't tested the `https`
support [yet].
* Include final bit of doc string sentence.
I trimmed the docstring that I lifed from https://nginx.org/en a bit
too aggressively and left a '...' to remind me to fix it.
Apparently I need more obvious reminders.
Thanks @davydden!
* Install the shell completion scripts
Install the `git-completion.{bash,tcsh,zsh}` and `git-prompt.sh` into
`$(spack location -i git)/share/` (aka `prefix.share/`).
* Use copy_tree to copy all the files
The dest dir already exists, so install_tree()'s not an option.
* Added a package for the MDAnalysis toolkit.
* Added the dependency on setuptools.
* Added the rest of the dependencies to the py-mdanalysis package. Also
added the griddataformats and seaborn packages to satisfy requirements.
* Removed seaborn package since it has been recently added.
* Fixed flake8 error
* Removed inadvertent commits.
* Cleaned up reviewers feedback.
Update the package recipe w.r.t. AutotoolsPackage changes,
now builds "out of source".
Update the package with version info for 1.3.0.
> Mosh 1.3.0 released, with John Hood as release lead. The release includes broader platform compatibility, robustness improvements, better testing, and fixes for excess CPU consumption in some cases. We have switched to semver.org-style versioning and will increment the minor version number whenever we add new functionality. (In our previous practice, this release would probably have been called “1.2.7.”)
Tested on CentOS 7.
* adding 0.5.1 and variant for uint8 bit stream word type
* Revisions as per davydden
* fixing style (flake8) issues
* - switched to derive from MakefilePackage
- fixed typo in variant check
- Confirmed installs correctly with bswtuint8 variant
* added build method; changed zfp_incdir to incdir
* Add the rockstar package
* Add rockstar to yt.
* Correct signature of prep_yt.
* Correct rockstar package installation process
Needed to change the way the necessary prefixes are found as well as
how the completed package is copied.
There should probably be a way to do the copying in a more 'spack' way.
* Add license
* Add description.
* Set no hdf5 variant as default.
* Use copy_tree for copying files
* Use MakefilePackage
* Address concerns from @adamjstewart
* Fix flake8 errors.
Adds a package for mallocMC, a memory allocator for many core
architectures.
This project provides a framework for fast memory managers on
many core accelerators. Currently, it supports NVIDIA GPUs of
compute capability sm_20 or higher through the ScatterAlloc
algorithm. mallocMC is header-only.
Downstream Dependencies
PIConGPU and other projects of HZDR's
*Computational Radiation Physics* group
References
- Markus Steinberger, Michael Kenzel, Bernhard Kainz and Dieter Schmalstieg.
*ScatterAlloc: Massively parallel dynamic memory allocation for the GPU*,
Innovative Parallel Computing (InPar), 2012,
https://doi.org/10.1109/InPar.2012.6339604
- Carlchristian Eckert.
*Enhancements of the massively parallel memory allocator ScatterAlloc and its adaption to the general interface mallocMC*,
Junior Thesis (grosser Beleg), 2014,
http://dx.doi.org/10.5281/zenodo.34461
This adds a maintained version of the (since 2012)
stalled original project.
https://github.com/ComputationalRadiationPhysics/cuda_memtest
Nvidia's NVML (via the GPU deployment kit) could also be
added, providing serial number output of failing GPUs
for multi-GPU nodes.
