Perl installs a couple of config files that need to be munged so that
they don't refer to the spack compiler. These files are installed
read-only. Behind the scenes 'filter_file' moves its file to a safe
place, and tries to create a working file that is both O_WRONLY and
has the perms of the original file. On an NFSv4 filesystem, the
combination of 'r--r--r--' and O_WRONLY throws a permissions error.
This commit adds a simple context manager that temporarily makes the
files writable.
* perl: prepend default perl @INC path to support package activation
* perl: remove stray comma from list of configure arguments
* perl: final comma in configure arguments makes adding arguments safer
This reverts commit fdc10cd611f525ebc31ca1953e048095b1c75350.
* perl: add comment about modified @INC (thanks to George Hartzell)
* perl: use self.prefix.lib and self.prefix.bin for clarity
* perl: convert tabs added by editor to spaces for flake8
* perl: use new path syntax: prefix.lib.perl5
* perl: avoid line break before binary operator
* perl: use compact spack syntax for perl executable
* Add variant to build shared Perl lib
Add a variant that enables Perl's "useshrplib" feature, which builds a
shared perl library.
This addresses problems like so:
```
/usr/bin/ld: /blah/blah/spack/opt/spack/linux-centos7-x86_64/gcc-4.8.5/perl-5.24.1-y43dp3p5w66v7qh5xkwgufxohyuodyew/lib/5.24.1/x86_64-linux/CORE/libperl.a(op.o): relocation R_X86_64_32S against `PL_opargs' can not be used when making a shared object; recompile with -fPIC
/blah/blah/spack/opt/spack/linux-centos7-x86_64/gcc-4.8.5/perl-5.24.1-y43dp3p5w66v7qh5xkwgufxohyuodyew/lib/5.24.1/x86_64-linux/CORE/libperl.a: could not read symbols: Bad value
```
It should also address the Intel compiler issue discussed in #3081
while respecting Perl's configuration machinery.
* Rename shared variant and default to True
* Use correct variant to add configure arg
* Restore bits that set ccflags for intel compilers
After some experimentation we've established that setting
the flag to build a shared perl library is tightly tied to
the use of -fPIC.
This commit restores the code that sets ccflags for
intel compilers.
* Flake8 cleanup
* Ensure Config.pm has correct setting for cc
Run a filter after install so that Config.pm records the compiler that
Spack built the package with. If this isn't done, $Config{cc} will be
set to Spack's cc wrapper script.
* Also patch compilers Config_heavy.pl
This patch sets ld=gcc, which appears to work. I'm not sure if
there's a good way to get at the ld that Spack uses.
* Clean up quoting
* Fix pattern for Config.pm
Does not start at beginning of line...
## 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.
* 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
* perl: make extendable and add Module::Build package
* perl: allow 'spack create' to identify perl packages from their contents
* perl-module-build: fix indenting of package docstring
* perl: split install() method for extensions into phases
* perl: auto-detect build method (Makefile.PL vs Build.PL) and define a 'check' method
* PerlPackage: use import statements similar to those in AutotoolsPackage
* PerlModule: fix detection of Build.PL
* PerlPackageTemplate: remove extraneous lines to avoid flake8 warnings
* PerlPackageTemplate: split into separate templates for Makefile.PL and Build.PL
* PerlPackage: add cross-references to docstrings
* AutotoolsPackage: fix ambiguous cross-references to avoid errors in doc tests
* PerlbuildPackageTemplate: depend on perl-module-build if Build.PL exists
Use the resource machinery to fetch/cache/unpack/... the App::cpanminus
tarball.
- this hardcodes the version, I can't figure out how to use a variant to
hold/set the value and access it in the resource().
- change up the install to use the `with working_dir()` meme.
Make running perl's tests conditional, one must now specify the
`--run-tests` flag to the `spack install` command in order to run the
tests.
On one system (8 core, 16GB Digital Ocean Droplet), installing without
tests takes 3 minutes, with tests takes 16 minutes.
Rather than hard-coding the verison of `cpanm` that's [optionally]
installed into the core, make it a variant with a default value of
'1.7042'.
Also discovered that `prefix + 'bin'` is the same as `prefix.bin`, so
embetter that bit of code.
Add perl package, based on [work by
justintoo](https://github.com/LLNL/spack/pull/105). He had too many
things pulled into that pull request, this just adds a perl package.
Support the current releases on the past three minor branches.
Run perl's tests before installing.
Install cpanm into the core (makes building on top of this perl *much*
simpler). Controlled by a variant.
