* python: ensure that distutils sets valid compiler options for RPATH on cray
* python: add cray-rpath patches for python@2.3:3.0.1 and python@3.1:
* python: in patch(..., when="@a:b platform=c"), limit b must be specified
* python: assume that python@4 will break the cray patches
* Fix mummerplot when ^perl@5.20:
Calling defined() on a hash has been deprecated for ages. It became
an error in perl@5.20. If we're building with a perl where it's
illegal, we should fix it.
* Simplify call to filter_file
Treat the first arg to filter_file as a string rather than
a regex, so that we don't have to figure out the escapes.
* Patch mummerplot for *any* perl version.
* Fix bwa url's
Work around varying github URLs.
See #4365 for details.
* Restore main url entry
@adamjstewart pointed out that the package still needs a main url
so that `spack versions` works.
- Add a `spack gpg` subcommand in anticipation of signed binaries.
- GPG keys are stored in var/spack/gpg, and the spack gpg command manages them.
- Docs are included on the command.
* Add info for jdk@7u80 (not downloadable)
Add version info for jdk@7u80. Oracle does't seem to be
distributing it any longer so there's no reasonable URL to
provide, but for those of us who already have the tarball
this is useful.
* Flake8 cleanup
* Add mpi support to R
* Add multiple precision math routines to R
* Updated the URL to match the version
* Remove duplicate packages
* Add packages for r-ergm and it's dependents
* Fixed depends-on types
* Correct flake8 errors
* Correct Build type
* r-adegenet and dependent packages
* fix parser
* Removed xfails
* cleaned up debug print statements
* make use of these changes in gcc
* Added comment explaining unreachable line, line left for added protection
* cairo: ensure that X support is disabled for variant "~X"
* cairo: explicitly enable X support for +X variant
* cairo: prefer "variant in spec" over spec.satisfies(variant)
* Trailing whitespace cleanup
* Handcraft an install process for mummer (grumble)
Mummer punts on an installation step, they just build in and run from
the same directory.
Mummer also has various hardcoded paths built into it that allow it to
find other executables that it needs as well as its Perl library.
This updates the package to deal with this approach.
It patches the Makefile and scripts/Makefile so that the correct info
is fed to sed when it munges the perl scripts.
The install step is now finer grained and puts things where mummer
relatively wants to find them.
* Add perl dependency
* perl should be build/run dependency
* Fix whitespace
* Delete stray u at top of file
Two changes:
- It seems that Illumina version numbers are dotted and that the
dashed version in the 2.18... filename is an anomaly (based on the
names for 2.17.1.14 and 2.19.0). `url_for_version` does the right
thing for 2.18. It will need to be fixed when support for 2.19 is
added. 2.17 is no longer generally available so it gets a pass.
- Add version and hash for 2.17.1.14.
2.17.1.14 is no longer distributed. If you have a copy of the
source tarball, you can drop it into a local mirror w/ the name
mirror/bcl2fastq2/bcl2fastq2-2.17.1.14.zip and go from there.
* Add mpi support to R
* Add multiple precision math routines to R
* Add packages for r-ergm and it's dependents
* Fixed depends-on types
* Correct flake8 errors
* flex: create variant +lex that creates symlinks for lex and libl.{a,so}
* flex: enable variant +lex by default
* flex: use dso_suffix for portability; replace repetitive code with a loop
I need boost@1.54.0 for bcl2fastq2. I tested bcl2fastq2 using the
system compiler (gcc@4.8.5). My full build uses a spack-build
gcc@5.4.0.
boost@1.54.0 won't build. I found the answer
[here](https://github.com/hashdist/hashstack/issues/802) with the
details in [this upstream/boost
ticket](https://svn.boost.org/trac/boost/ticket/10125).
I've confirmed that these combo's build:
boost version| compiler
------------ | ------------------
boost@1.54.0 | gcc@4.8.5 (system)
boost@1.54.0 | gcc@5.4.0 (Spack)
boost@1.64.0 | gcc@5.5.0 (system)
* added openmpi support to meme
* openmpi is a link dependency which leverages r_path
* openmpi support now the default - meme does not have configure argument for mpi - if it's found then it's used
* added serial option and set mpi to not be default
* modified meme
* Add the gnupg package and missing dependencies. Update versions of existing dependencies.
* this ended up in the wrong repo
* put versions back, remove uneeded function
* OK ;)
* autopep8
* typo on npth line
* whitespace
* Add a new package for Open Babel
* Add post-installation tests, stolen from the fine folks at Homebrew
* Add patch to fix Python 3.6 support
* Add a more complete patch to get Python 3.6 support working
* Add patch to convert tabs to spaces in test script
testpdbformat.py contains mixed tabs and spaces
causing the unit tests to fail. With this patch,
all tests pass with flying colors.
* Add v1.1.26 and make crypto a variant
I need 1.1.26 for bcl2fastq2.
I also need to build it without crypto support.
* Initial support for bcl2fastq2
* Clean up commentary, messages, names
No substantial changes intended, just cleanup.
* fix flake8 and extra import
* The masked grammarian strikes again...
* Be normal (messages don't end in periods)
* When +crypto, add --with-crypto
Add `--with-crypto` to configure args when user hasn't explicitly set
`~crypto`.
* self.spec.satisfies is unsatisfying, in is in instead
See #4135, self.spec.satisfies has issues. @adamjstewart suggests
simply using in.
* added albacore package as well as dependency py-ont-fast5-api
* added py-cutadapt and dependency py-xopen
* made more changes to albacore and cutadapt as well as dependencies
* made changes again per @adamjstewart
* fixed by python n00b errors i think
* fixed?
* tw=79
* made changes to py-ont-fast5-api ont-albacore
* removed bad characters
* albacore requires setuptools as build and run dependency
* added vmd
* added back albacore
* removed vmd package
* added meme software
* libz is only needed as link depedency for meme
* added libxml2 libxslt libgcrypt as link dependencies
* added albacore package as well as dependency py-ont-fast5-api
* added py-cutadapt and dependency py-xopen
* made more changes to albacore and cutadapt as well as dependencies
* made changes again per @adamjstewart
* fixed by python n00b errors i think
* fixed?
* tw=79
* made changes to py-ont-fast5-api ont-albacore
* removed bad characters
* py-cdat-lite: a python package for managing and analysing climate science data
* py-cdat-lite: depends on py-numpy
* py-cdat-lite: flake8 compliance
* py-cdat-lite: provide a generic URL where multiple versions are listed
* py-cdat-lite: restrict python versions; python required at run-time
* py-cdat-lite: use URL under pypi.io for consistency with other packages
* py-cdat-lite: add run-time dependency on py-numpy
* Initial attempt at flann packaging.
Python2 somehow works. Python3 does not. Still debugging their
obscure setup.py configuration.
* Flann good enough. Python3 broken but close.
Flake8 checks in place. Unsure about CMAKE_BUILD_TYPE and default
spack behavior.
* spack uses RelWithDebInfo as default build type.
* builds py2/3, but direct site-packages install
* prefix working, empty python install dir
* flann package +python installs correctly
* str format {0} instead of {}
* potential doctest fix
* consistency of build env with PythonPackage
* fix python again, test deptype todo, build type
* potentially enable matlab, untested
* highfive: New package; this is a C++ wrapper for the HDF5 library
The C++ wrapper that is shipped with the HDF5 library has several shortcomings. The highfive library seems to avoid these.
* highfive: Make MPI variant default to true
* enable cuda support for suite-sparse
* do not use spec.satisfies
* cuda restructure, give clearer comment of why
* str format compatibility
* flake8 checks
* 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
* * Adding uber fastmath package to support 'spack install fastmath'
* Adding dims variant boxlib to control compile-time spatial dimension count
* Explicitly disabling many parts of moab to get lib to build. Don't need tools yet.
* Add logic to spack/setup-env to not refer to $SYS_TYPE if its not defined.
* adding mesquite package
* * Added Chombo (still working on Fortran name mangling)
* Made mesquite depend on mpi
* Fixed use of boxlib's dims numerical variant
* adding PUMI
* flake8 compliance
* adding phasta
* fixing flake8 issues
* undue $SYS_TYPE protection change
* fixing install step for fastmath uber package; resolve issues requested by adamjstewart in PR
* revisions as per adamjstewart
* re-enabling trilinos and phasta dependencies
* all changes requested modulu values= and assert statement
* fixing cmake_args usage in pumi; fixing lib installs for chombo
* first pass at numerical variant
* fixing dims variant as per @adamjstewart
* fixing func/var name collision
* fixing means of disabling -Werror
* fix name collision for cmake_args var/func
* fixing chombo homepage/url; make FASTMath use chombo#3.2; remove extraneous comment about boxlib dim
* remove dummy fastmath package; switch to @BarrySmith soln for install of dummy bundle
* fix flake8 import os issue
* remove extraneous comment
* adding url for fastmath scidac site
* final fixes as per @adamjstewart
* adding 1 dims option for boxlib
* switching make(all) to gmake(all)
Added DFLAGS to the `make.inc` file being written.
These macros are also added to the language specific variables
like CFLAGS, CXXFLAGS and FCFLAGS. Changed `spec.satisfies('foo')`
with `'foo' in spec` in `intel-mkl`, see #4135. Added a basic
build interface to `intel-mpi`.
* Add GCC 7
* Allow users to build subset of GCC compilers with multi-value variant.
* Add comment explaining what 'all' actually means
* More specific golang support
* Only require Zip when building Java
* Comment out provide directives that don't currently work
* Add Ada support
* Use conflicts directive
* Fix joining of languages
* Need special flag to build jit
* Explicitly declare GNAT download extension
* Import tty, update lib64 to lib
* BRIG and Go are not supported on macOS
* Simplify formatting and imports
* JIT patch required for newer versions as well
* Updating bamtools to include a dependency for zlib.
In a standard compile, bamtools will fail if zlib headers are not installed on the target machine. In order to maintain compatibility with all systems -- and since zlib is included already as a dependency for cmake -- this patch adds zlib as a link dependency for the bamtools package.
* Modified cmake rpath include.
Bamtools has a non-standard library location, so we need to append $prefix/lib/bamtools to the rpath. Not sure there's a better way to do this...
* Fixing syntax error in package.py
Fixed a non-terminated parenthesis on line 46.
* Updated bamtools to be a CMakePackage
Removed extraneous code, and altered the package to extend cmake_args
including the non-standard library location.
* UpRemoving cmake dependency and removing blank line from end of file
* Updates to cmake_args.
Removed the duplicate definition of std_cmake_args in favor of simply overriding the CMAKE_INSTALL_RPATH variable that is provided. This should allow the package to be linked correctly to itself.
python+tk will not build because it depends (indirectly) on python~tk
via libxcb. There are efforts to allow multiple instances of a package
to concretize together but they are ongoing so in the meantime this
comments out the dependencies and adds TODOs
* SV variants are evaluated correctly in `when=` statements fixes#4113
The problem here was tricky:
```python
spec.satisfies(other)
```
changes already the MV variants in others into SV variants (where
necessary) if spec is concrete. If it is not concrete it does
nothing because we may be acting at a pure syntactical level.
When evaluating a `when=` keyword spec is for sure not concrete
as it is in the middle of the concretization process. In this case we
have to trigger manually the substitution in other to not end up
comparing a MV variant "foo=bar" to a SV variant "foo=bar" and having
False in return. Which is wrong.
* sv variants: improved error message for typos in "when=" statements
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
