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

269 lines
11 KiB
Python
Raw Normal View History

# Copyright 2013-2019 Lawrence Livermore National Security, LLC and other
# Spack Project Developers. See the top-level COPYRIGHT file for details.
#
# SPDX-License-Identifier: (Apache-2.0 OR MIT)
import os
2015-11-24 05:48:06 +08:00
from spack import *
from spack.package_test import compare_output_file, compile_c_and_execute
import spack.architecture
2016-05-11 21:45:57 +08:00
2015-11-24 05:48:06 +08:00
class Openblas(MakefilePackage):
2015-11-24 05:48:06 +08:00
"""OpenBLAS: An optimized BLAS library"""
2019-10-21 06:06:30 +08:00
homepage = 'https://www.openblas.net'
url = 'https://github.com/xianyi/OpenBLAS/archive/v0.2.19.tar.gz'
git = 'https://github.com/xianyi/OpenBLAS.git'
2015-11-24 05:48:06 +08:00
version('develop', branch='develop')
version('0.3.7', sha256='bde136122cef3dd6efe2de1c6f65c10955bbb0cc01a520c2342f5287c28f9379')
version('0.3.6', sha256='e64c8fe083832ffbc1459ab6c72f71d53afd3b36e8497c922a15a06b72e9002f')
2019-01-16 22:11:08 +08:00
version('0.3.5', sha256='0950c14bd77c90a6427e26210d6dab422271bc86f9fc69126725833ecdaa0e85')
2018-12-05 22:41:58 +08:00
version('0.3.4', sha256='4b4b4453251e9edb5f57465bf2b3cf67b19d811d50c8588cdf2ea1f201bb834f')
2018-09-01 02:14:37 +08:00
version('0.3.3', sha256='49d88f4494ae780e3d7fa51769c00d982d7cdb73e696054ac3baa81d42f13bab')
2018-08-02 08:14:48 +08:00
version('0.3.2', sha256='e8ba64f6b103c511ae13736100347deb7121ba9b41ba82052b1a018a65c0cb15')
version('0.3.1', sha256='1f5e956f35f3acdd3c74516e955d797a320c2e0135e31d838cbdb3ea94d0eb33')
version('0.3.0', sha256='cf51543709abe364d8ecfb5c09a2b533d2b725ea1a66f203509b21a8e9d8f1a1')
version('0.2.20', sha256='5ef38b15d9c652985774869efd548b8e3e972e1e99475c673b25537ed7bcf394')
version('0.2.19', sha256='9c40b5e4970f27c5f6911cb0a28aa26b6c83f17418b69f8e5a116bb983ca8557')
version('0.2.18', sha256='7d9f8d4ea4a65ab68088f3bb557f03a7ac9cb5036ef2ba30546c3a28774a4112')
version('0.2.17', sha256='0fe836dfee219ff4cadcc3567fb2223d9e0da5f60c7382711fb9e2c35ecf0dbf')
version('0.2.16', sha256='766f350d0a4be614812d535cead8c816fc3ad3b9afcd93167ea5e4df9d61869b')
version('0.2.15', sha256='73c40ace5978282224e5e122a41c8388c5a19e65a6f2329c2b7c0b61bacc9044')
variant(
'shared',
default=True,
description='Build shared libraries as well as static libs.'
)
2017-09-12 14:40:28 +08:00
variant('ilp64', default=False, description='64 bit integers')
variant('pic', default=True, description='Build position independent code')
Multi-valued variants: better support for combinations (#9481) This enforces conventions that allow for correct handling of multi-valued variants where specifying no value is an option, and adds convenience functionality for specifying multi-valued variants with conflicting sets of values. This also adds a notion of "feature values" for variants, which are those that are understood by the build system (e.g. those that would appear as configure options). In more detail: * Add documentation on variants to the packaging guide * Forbid usage of '' or None as a possible variant value, in particular as a default. To indicate choosing no value, the user must explicitly define an option like 'none'. Without this, multi-valued variants with default set to None were not parsable from the command line (Fixes #6314) * Add "disjoint_sets" function to support the declaration of multi-valued variants with conflicting sets of options. For example a variant "foo" with possible values "a", "b", and "c" where "c" is exclusive of the other values ("foo=a,b" and "foo=c" are valid but "foo=a,c" is not). * Add "any_combination_of" function to support the declaration of multi-valued variants where it is valid to choose none of the values. This automatically defines "none" as an option (exclusive with all other choices); this value does not appear when iterating over the variant's values, for example in "with_or_without" (which constructs autotools option strings from variant values). * The "disjoint_sets" and "any_combination_of" methods return an object which tracks the possible values. It is also possible to indicate that some of these values do not correspond to options understood by the package's build system, such that methods like "with_or_without" will not define options for those values (this occurs automatically for "none") * Add documentation for usage of new functions for specifying multi-valued variants
2019-01-05 11:02:34 +08:00
variant('cpu_target', default='auto',
description='Set CPU target architecture (leave empty for '
'autodetection; GENERIC, SSE_GENERIC, NEHALEM, ...)')
variant(
'threads', default='none',
description='Multithreading support',
values=('pthreads', 'openmp', 'none'),
multi=False
)
variant(
'virtual_machine',
default=False,
description="Adding options to build openblas on Linux virtual machine"
)
variant(
'avx2',
default=True,
description='Enable use of AVX2 instructions'
)
variant(
'avx512',
default=False,
description='Enable use of AVX512 instructions'
)
2015-11-24 05:48:06 +08:00
# virtual dependency
provides('blas')
provides('lapack')
# OpenBLAS >=3.0 has an official way to disable internal parallel builds
patch('make.patch', when='@0.2.16:0.2.20')
# This patch is in a pull request to OpenBLAS that has not been handled
# https://github.com/xianyi/OpenBLAS/pull/915
# UPD: the patch has been merged starting version 0.2.20
patch('openblas_icc.patch', when='@:0.2.19%intel')
patch('openblas_icc_openmp.patch', when='@:0.2.20%intel@16.0:')
patch('openblas_icc_fortran.patch', when='%intel@16.0:')
2017-11-23 22:28:35 +08:00
patch('openblas_icc_fortran2.patch', when='%intel@18.0:')
# Fixes compilation error on POWER8 with GCC 7
# https://github.com/xianyi/OpenBLAS/pull/1098
patch('power8.patch', when='@0.2.18:0.2.19 %gcc@7.1.0: target=power8')
# Change file comments to work around clang 3.9 assembler bug
# https://github.com/xianyi/OpenBLAS/pull/982
patch('openblas0.2.19.diff', when='@0.2.19')
# Fix CMake export symbol error
# https://github.com/xianyi/OpenBLAS/pull/1703
patch('openblas-0.3.2-cmake.patch', when='@0.3.1:0.3.2')
# Disable experimental TLS code that lead to many threading issues
# https://github.com/xianyi/OpenBLAS/issues/1735#issuecomment-422954465
# https://github.com/xianyi/OpenBLAS/issues/1761#issuecomment-421039174
# https://github.com/xianyi/OpenBLAS/pull/1765
patch('https://github.com/xianyi/OpenBLAS/commit/4d183e5567346f80f2ef97eb98f8601c47f8cb56.patch',
sha256='714aea33692304a50bd0ccde42590c176c82ded4a8ac7f06e573dc8071929c33',
when='@0.3.3')
# Fix parallel build issues on filesystems
# with missing sub-second timestamp resolution
patch('https://github.com/xianyi/OpenBLAS/commit/79ea839b635d1fd84b6ce8a47e086f01d64198e6.patch',
sha256='f1b066a4481a50678caeb7656bf3e6764f45619686ac465f257c8017a2dc1ff0',
when='@0.3.0:0.3.3')
# Add conditions to f_check to determine the Fujitsu compiler
patch('openblas_fujitsu.patch', when='%fj')
conflicts('%intel@16', when='@0.2.15:0.2.19')
@property
def parallel(self):
# unclear whether setting `-j N` externally was supported before 0.3
return self.spec.version >= Version('0.3.0')
@run_before('edit')
def check_compilers(self):
# As of 06/2016 there is no mechanism to specify that packages which
# depends on Blas/Lapack need C or/and Fortran symbols. For now
# require both.
if self.compiler.fc is None:
raise InstallError(
'OpenBLAS requires both C and Fortran compilers!'
)
# Add support for OpenMP
if (self.spec.satisfies('threads=openmp') and
self.spec.satisfies('%clang')):
if str(self.spec.compiler.version).endswith('-apple'):
raise InstallError("Apple's clang does not support OpenMP")
if '@:0.2.19' in self.spec:
# Openblas (as of 0.2.19) hardcoded that OpenMP cannot
# be used with any (!) compiler named clang, bummer.
raise InstallError(
'OpenBLAS @:0.2.19 does not support OpenMP with clang!'
)
@property
def make_defs(self):
# Configure fails to pick up fortran from FC=/abs/path/to/fc, but
# works fine with FC=/abs/path/to/gfortran.
# When mixing compilers make sure that
# $SPACK_ROOT/lib/spack/env/<compiler> have symlinks with reasonable
# names and hack them inside lib/spack/spack/compilers/<compiler>.py
make_defs = [
'CC={0}'.format(spack_cc),
'FC={0}'.format(spack_fc),
]
# force OpenBLAS to use externally defined parallel build
if self.spec.version < Version('0.3'):
make_defs.append('MAKE_NO_J=1') # flag defined by our make.patch
else:
make_defs.append('MAKE_NB_JOBS=0') # flag provided by OpenBLAS
if self.spec.variants['virtual_machine'].value:
make_defs += [
'DYNAMIC_ARCH=1',
'NUM_THREADS=64', # OpenBLAS stores present no of CPUs as max
]
Multi-valued variants: better support for combinations (#9481) This enforces conventions that allow for correct handling of multi-valued variants where specifying no value is an option, and adds convenience functionality for specifying multi-valued variants with conflicting sets of values. This also adds a notion of "feature values" for variants, which are those that are understood by the build system (e.g. those that would appear as configure options). In more detail: * Add documentation on variants to the packaging guide * Forbid usage of '' or None as a possible variant value, in particular as a default. To indicate choosing no value, the user must explicitly define an option like 'none'. Without this, multi-valued variants with default set to None were not parsable from the command line (Fixes #6314) * Add "disjoint_sets" function to support the declaration of multi-valued variants with conflicting sets of options. For example a variant "foo" with possible values "a", "b", and "c" where "c" is exclusive of the other values ("foo=a,b" and "foo=c" are valid but "foo=a,c" is not). * Add "any_combination_of" function to support the declaration of multi-valued variants where it is valid to choose none of the values. This automatically defines "none" as an option (exclusive with all other choices); this value does not appear when iterating over the variant's values, for example in "with_or_without" (which constructs autotools option strings from variant values). * The "disjoint_sets" and "any_combination_of" methods return an object which tracks the possible values. It is also possible to indicate that some of these values do not correspond to options understood by the package's build system, such that methods like "with_or_without" will not define options for those values (this occurs automatically for "none") * Add documentation for usage of new functions for specifying multi-valued variants
2019-01-05 11:02:34 +08:00
if self.spec.variants['cpu_target'].value != 'auto':
make_defs += [
'TARGET={0}'.format(self.spec.variants['cpu_target'].value)
]
# invoke make with the correct TARGET for aarch64
elif 'aarch64' in spack.architecture.sys_type():
make_defs += [
'TARGET=ARMV8'
]
if self.spec.satisfies('%gcc@:4.8.4'):
make_defs += ['NO_AVX2=1']
if '~shared' in self.spec:
if '+pic' in self.spec:
make_defs.extend([
'CFLAGS={0}'.format(self.compiler.pic_flag),
'FFLAGS={0}'.format(self.compiler.pic_flag)
])
make_defs += ['NO_SHARED=1']
# fix missing _dggsvd_ and _sggsvd_
if self.spec.satisfies('@0.2.16'):
make_defs += ['BUILD_LAPACK_DEPRECATED=1']
# Add support for multithreading
if self.spec.satisfies('threads=openmp'):
make_defs += ['USE_OPENMP=1', 'USE_THREAD=1']
elif self.spec.satisfies('threads=pthreads'):
make_defs += ['USE_OPENMP=0', 'USE_THREAD=1']
else:
make_defs += ['USE_OPENMP=0', 'USE_THREAD=0']
2016-04-12 05:28:30 +08:00
2017-09-12 14:40:28 +08:00
# 64bit ints
if '+ilp64' in self.spec:
make_defs += ['INTERFACE64=1']
if self.spec.target.family == 'x86_64':
if '~avx2' in self.spec:
make_defs += ['NO_AVX2=1']
if '~avx512' in self.spec:
make_defs += ['NO_AVX512=1']
return make_defs
@property
def headers(self):
# As in netlib-lapack, the only public headers for cblas and lapacke in
# openblas are cblas.h and lapacke.h. The remaining headers are private
# headers either included in one of these two headers, or included in
# one of the source files implementing functions declared in these
# headers.
return find_headers(['cblas', 'lapacke'], self.prefix.include)
@property
def build_targets(self):
targets = ['libs', 'netlib']
# Build shared if variant is set.
if '+shared' in self.spec:
targets += ['shared']
2015-11-24 05:48:06 +08:00
return self.make_defs + targets
@run_after('build')
2017-04-22 01:15:39 +08:00
@on_package_attributes(run_tests=True)
def check_build(self):
make('tests', *self.make_defs, parallel=False)
@property
def install_targets(self):
make_args = [
'install',
'PREFIX={0}'.format(self.prefix),
]
return make_args + self.make_defs
@run_after('install')
2017-04-22 01:15:39 +08:00
@on_package_attributes(run_tests=True)
def check_install(self):
spec = self.spec
# Openblas may pass its own test but still fail to compile Lapack
2016-05-11 21:45:57 +08:00
# symbols. To make sure we get working Blas and Lapack, do a small
# test.
source_file = join_path(os.path.dirname(self.module.__file__),
'test_cblas_dgemm.c')
blessed_file = join_path(os.path.dirname(self.module.__file__),
'test_cblas_dgemm.output')
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
include_flags = spec['openblas'].headers.cpp_flags
2017-03-04 09:30:35 +08:00
link_flags = spec['openblas'].libs.ld_flags
if self.compiler.name == 'intel':
link_flags += ' -lifcore'
if self.spec.satisfies('threads=pthreads'):
link_flags += ' -lpthread'
if spec.satisfies('threads=openmp'):
link_flags += ' -lpthread ' + self.compiler.openmp_flag
output = compile_c_and_execute(
source_file, [include_flags], link_flags.split()
)
2016-05-11 21:45:57 +08:00
compare_output_file(output, blessed_file)