spack/var/spack/repos/builtin/packages/julia/package.py

246 lines
9.7 KiB
Python
Raw Normal View History

##############################################################################
# Copyright (c) 2013-2018, Lawrence Livermore National Security, LLC.
# Produced at the Lawrence Livermore National Laboratory.
#
# This file is part of Spack.
# Created by Todd Gamblin, tgamblin@llnl.gov, All rights reserved.
# LLNL-CODE-647188
#
# For details, see https://github.com/spack/spack
# Please also see the NOTICE and LICENSE files for our notice and the LGPL.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License (as
# published by the Free Software Foundation) version 2.1, February 1999.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the IMPLIED WARRANTY OF
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the terms and
# conditions of the GNU Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
##############################################################################
2016-06-22 23:09:45 +08:00
2015-12-23 07:54:47 +08:00
from spack import *
import os
import sys
2016-06-22 23:09:45 +08:00
2015-12-23 07:54:47 +08:00
class Julia(Package):
"""The Julia Language: A fresh approach to technical computing"""
2015-12-23 07:54:47 +08:00
homepage = "http://julialang.org"
url = "https://github.com/JuliaLang/julia/releases/download/v0.4.3/julia-0.4.3-full.tar.gz"
git = "https://github.com/JuliaLang/julia.git"
2015-12-23 07:54:47 +08:00
version('master', branch='master')
version('0.6.2', '255d80bc8d56d5f059fe18f0798e32f6')
version('release-0.5', branch='release-0.5')
version('0.5.2', '8c3fff150a6f96cf0536fb3b4eaa5cbb')
2017-05-20 06:32:40 +08:00
version('0.5.1', 'bce119b98f274e0f07ce01498c463ad5')
version('0.5.0', 'b61385671ba74767ab452363c43131fb')
version('release-0.4', branch='release-0.4')
2016-09-21 03:40:58 +08:00
version('0.4.7', '75a7a7dd882b7840829d8f165e9b9078')
2016-09-20 17:16:25 +08:00
version('0.4.6', 'd88db18c579049c23ab8ef427ccedf5d')
version('0.4.5', '69141ff5aa6cee7c0ec8c85a34aa49a6')
version('0.4.3', '8a4a59fd335b05090dd1ebefbbe5aaac')
2015-12-23 07:54:47 +08:00
# TODO: Split these out into jl-hdf5, jl-mpi packages etc.
variant("cxx", default=False, description="Prepare for Julia Cxx package")
variant("hdf5", default=False, description="Install Julia HDF5 package")
variant("mpi", default=True, description="Install Julia MPI package")
variant("plot", default=False,
description="Install Julia plotting packages")
variant("python", default=False,
description="Install Julia Python package")
2017-03-17 00:49:37 +08:00
variant("simd", default=False, description="Install Julia SIMD package")
2016-06-22 23:00:00 +08:00
patch('gc.patch', when='@0.4:0.4.5')
patch('openblas.patch', when='@0.4:0.4.5')
variant('binutils', default=sys.platform != 'darwin',
description="Build via binutils")
# Build-time dependencies:
# depends_on("awk")
depends_on("m4", type="build")
# depends_on("pkgconfig")
2015-12-23 07:54:47 +08:00
# Combined build-time and run-time dependencies:
# (Yes, these are run-time dependencies used by Julia's package manager.)
depends_on("binutils", when='+binutils')
depends_on("cmake @2.8:")
depends_on("curl")
depends_on("git", when='@:0.4')
depends_on("git", when='@release-0.4')
depends_on("openssl")
depends_on("python@2.7:2.8")
2015-12-23 21:40:55 +08:00
# Run-time dependencies:
2015-12-23 21:40:55 +08:00
# depends_on("arpack")
# depends_on("fftw +float")
# depends_on("gmp")
# depends_on("libgit")
2015-12-23 21:40:55 +08:00
# depends_on("mpfr")
# depends_on("openblas")
2015-12-23 21:40:55 +08:00
# depends_on("pcre2")
# ARPACK: Requires BLAS and LAPACK; needs to use the same version
# as Julia.
2015-12-23 07:54:47 +08:00
# BLAS and LAPACK: Julia prefers 64-bit versions on 64-bit
# systems. OpenBLAS has an option for this; make it available as
# variant.
2015-12-23 07:54:47 +08:00
# FFTW: Something doesn't work when using a pre-installed FFTW
# library; need to investigate.
2015-12-23 21:40:55 +08:00
# GMP, MPFR: Something doesn't work when using a pre-installed
# FFTW library; need to investigate.
2015-12-23 21:40:55 +08:00
# LLVM: Julia works only with specific versions, and might require
# patches. Thus we let Julia install its own LLVM.
2015-12-23 07:54:47 +08:00
# Other possible dependencies:
# USE_SYSTEM_OPENLIBM=0
# USE_SYSTEM_OPENSPECFUN=0
# USE_SYSTEM_DSFMT=0
# USE_SYSTEM_SUITESPARSE=0
# USE_SYSTEM_UTF8PROC=0
# USE_SYSTEM_LIBGIT2=0
# Run-time dependencies for Julia packages:
depends_on("hdf5", when="+hdf5", type="run")
depends_on("mpi", when="+mpi", type="run")
depends_on("py-matplotlib", when="+plot", type="run")
2015-12-23 07:54:47 +08:00
def install(self, spec, prefix):
# Julia needs git tags
if os.path.isfile(".git/shallow"):
git = which("git")
git("fetch", "--unshallow")
# Explicitly setting CC, CXX, or FC breaks building libuv, one
# of Julia's dependencies. This might be a Darwin-specific
# problem. Given how Spack sets up compilers, Julia should
# still use Spack's compilers, even if we don't specify them
# explicitly.
2016-06-22 23:09:45 +08:00
options = [
# "CC=cc",
# "CXX=c++",
# "FC=fc",
# "USE_SYSTEM_ARPACK=1",
"override USE_SYSTEM_CURL=1",
2016-06-22 23:09:45 +08:00
# "USE_SYSTEM_FFTW=1",
# "USE_SYSTEM_GMP=1",
# "USE_SYSTEM_MPFR=1",
# "USE_SYSTEM_PCRE=1",
"prefix=%s" % prefix]
if "+cxx" in spec:
if "@master" not in spec:
raise InstallError(
"Variant +cxx requires the @master version of Julia")
options += [
"BUILD_LLVM_CLANG=1",
"LLVM_ASSERTIONS=1",
"USE_LLVM_SHLIB=1"]
2015-12-23 07:54:47 +08:00
with open('Make.user', 'w') as f:
f.write('\n'.join(options) + '\n')
make()
make("install")
# Julia's package manager needs a certificate
cacert_dir = join_path(prefix, "etc", "curl")
mkdirp(cacert_dir)
cacert_file = join_path(cacert_dir, "cacert.pem")
curl = which("curl")
curl("--create-dirs",
"--output", cacert_file,
"https://curl.haxx.se/ca/cacert.pem")
# Put Julia's compiler cache into a private directory
cachedir = join_path(prefix, "var", "julia", "cache")
mkdirp(cachedir)
# Store Julia packages in a private directory
pkgdir = join_path(prefix, "var", "julia", "pkg")
mkdirp(pkgdir)
# Configure Julia
with open(join_path(prefix, "etc", "julia", "juliarc.jl"),
"a") as juliarc:
2016-09-21 03:40:58 +08:00
if "@master" in spec or "@release-0.5" in spec or "@0.5:" in spec:
# This is required for versions @0.5:
juliarc.write(
'# Point package manager to working certificates\n')
juliarc.write('LibGit2.set_ssl_cert_locations("%s")\n' %
cacert_file)
juliarc.write('\n')
juliarc.write('# Put compiler cache into a private directory\n')
juliarc.write('empty!(Base.LOAD_CACHE_PATH)\n')
juliarc.write('unshift!(Base.LOAD_CACHE_PATH, "%s")\n' % cachedir)
juliarc.write('\n')
juliarc.write('# Put Julia packages into a private directory\n')
juliarc.write('ENV["JULIA_PKGDIR"] = "%s"\n' % pkgdir)
juliarc.write('\n')
# Install some commonly used packages
Python command, libraries, and headers (#3367) ## 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.
2017-04-30 08:24:13 +08:00
julia = spec['julia'].command
julia("-e", 'Pkg.init(); Pkg.update()')
# Install HDF5
if "+hdf5" in spec:
with open(join_path(prefix, "etc", "julia", "juliarc.jl"),
"a") as juliarc:
juliarc.write('# HDF5\n')
juliarc.write('push!(Libdl.DL_LOAD_PATH, "%s")\n' %
spec["hdf5"].prefix.lib)
juliarc.write('\n')
julia("-e", 'Pkg.add("HDF5"); using HDF5')
julia("-e", 'Pkg.add("JLD"); using JLD')
# Install MPI
if "+mpi" in spec:
with open(join_path(prefix, "etc", "julia", "juliarc.jl"),
"a") as juliarc:
juliarc.write('# MPI\n')
juliarc.write('ENV["JULIA_MPI_C_COMPILER"] = "%s"\n' %
join_path(spec["mpi"].prefix.bin, "mpicc"))
juliarc.write('ENV["JULIA_MPI_Fortran_COMPILER"] = "%s"\n' %
join_path(spec["mpi"].prefix.bin, "mpifort"))
juliarc.write('\n')
julia("-e", 'Pkg.add("MPI"); using MPI')
# Install Python
if "+python" in spec or "+plot" in spec:
with open(join_path(prefix, "etc", "julia", "juliarc.jl"),
"a") as juliarc:
juliarc.write('# Python\n')
Python command, libraries, and headers (#3367) ## 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.
2017-04-30 08:24:13 +08:00
juliarc.write('ENV["PYTHON"] = "%s"\n' % spec["python"].home)
juliarc.write('\n')
# Python's OpenSSL package installer complains:
# Error: PREFIX too long: 166 characters, but only 128 allowed
# Error: post-link failed for: openssl-1.0.2g-0
julia("-e", 'Pkg.add("PyCall"); using PyCall')
if "+plot" in spec:
julia("-e", 'Pkg.add("PyPlot"); using PyPlot')
julia("-e", 'Pkg.add("Colors"); using Colors')
# These require maybe gtk and image-magick
julia("-e", 'Pkg.add("Plots"); using Plots')
julia("-e", 'Pkg.add("PlotRecipes"); using PlotRecipes')
julia("-e", 'Pkg.add("UnicodePlots"); using UnicodePlots')
julia("-e", """\
using Plots
using UnicodePlots
unicodeplots()
plot(x->sin(x)*cos(x), linspace(0, 2pi))
""")
2017-03-17 00:49:37 +08:00
# Install SIMD
if "+simd" in spec:
julia("-e", 'Pkg.add("SIMD"); using SIMD')
julia("-e", 'Pkg.status()')