| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generalize the ILP64 BLAS/LAPACK symbol name handling to deal with
arbitrary prefix/suffix.
The build-time behavior is changed so that HAVE_BLAS_ILP64 and
BLAS_SYMBOL_SUFFIX/PREFIX defines are added to compile options
as appropriate.
Mainly to make autodetection of BLAS/LAPACK easier for downstream
numpy.distutils users, add get_info aliases 'blas_ilp64_opt',
'blas_ilp64_plain_opt', and 'blas64__opt' for any/no/""&"64_"
prefix&suffix, and the same for lapack. (Due to the way system_info
works, each also gets a separate class.)
In addition to openblas64_ which has a fixed suffix, add the (by default
suffixless) openblas_ilp64, which correspond to the most likely cases to
be present.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This is an emerging "standard" for 64-bit BLAS/LAPACK, avoiding symbol
clashes with 32-bit BLAS/LAPACK, originally introduced for Julia.
OpenBLAS can be compiled with 64-bit integer size and symbol suffix
'64_' (INTERFACE64=1 SYMBOLSUFFIX=64_). OpenBLAS built with this
setting is also provided by some Linux distributions (e.g. Fedora's
64-bit openblas packages).
|
| |
|
|
|
|
|
| |
Now libflame may be used as a LAPACK back-end.
libflame requires an external BLAS so one has to
also have this enabled.
Also added release notes for NPY_*_ORDER and libFLAME.
|
| |
|
| |
* BLD: use libraries as a key consistently in all site.cfg sections
|
| |\
| |
| | |
BUG: parse shell escaping in extra_compile_args and extra_link_args
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Thanks to a change in exec_command, these strings are no longer passed onto the shell.
Since config files do not support list values, our best bet is to perform shell-splitting immediately.
This brings the behavior back in line a little to how it was before.
On windows systems, the behavior has changed. Previously it was treated as a single argument unless it contained quotes, resulting in the following weird behavior:
# passes as one argument, preserving spaces
extra_link_args=-Wl,rpath=A:/path/with spaces
# passes as two arguments, preserving spaces
extra_link_args="-Wl,rpath=A:\path\with spaces" -lgfortran
# passes as one long quoted argument (surprising and undesirable)
extra_link_args=-Wl,rpath=A:\path\without_spaces -lgfortran
Now it behaves as windows escaping via subprocess (but _not_ via cmd) normally would:
# Passed as two separate arguments (probably not as intended, but should be expected)
extra_link_args=-Wl,rpath=A:/path/with spaces
# passes as two arguments, preserving spaces
extra_link_args="-Wl,rpath=A:\path\with spaces" -lgfortran
# passes as two arguments
extra_link_args=-Wl,rpath=A:\path\without_spaces -lgfortran
Fixes gh-12659
|
| | |
| |
| |
| | |
[ci skip]
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Remove the special-cased handling of OSX Accelerate/vecLib libraries,
and move the code (which was duplicated in two places) to a new
accelerate_info class, which is used in the same way as openblas/etc
libs.
Also add a configuration section and an environment variable for
controlling whether Accelerate/vecLib is to be used or not. Previously,
it was not possible to use generic BLAS/LAPACK instead of Accelerate on
OSX.
|
| |
|
|
| |
The MKL usage part is out-of-date for the recent releases of MKL. The old content does not work any work. This is an update on the MKL usage part. Some detail is reported here:
https://github.com/numpy/numpy/issues/10061
|
| |
|
|
| |
the files in doc/ and numpy/ were covered in previous commits
|
| |
|
|
| |
Closes #7572 inability to install in virtualenvs with percent in their path.
|
| |
|
|
| |
[ci skip]
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The extra_link_args is sadly not intrinsically used
for many parts of the system_info code.
This commit adds the linking properties stored
when using extra_link_args in the openblas section
to bypass any difficulties in the usage of OpenBLAS.
This is especially helpful when linking against external
LAPACK libraries which requires -lgfortran and possibly
-lm for correct linking.
|
| |
|
| |
"earch path" => "search path"
|
| |
|
|
|
|
|
|
|
| |
The original distutils assumes runtime_library_dirs to
be located in rpath, however, the internal structures assumes
the keyword to be runtime_library_dirs.
For now numpy.distutils handles both equivalently.
The test has been updated to also test the rpath solution.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A simple test (distutils/testing/test_system_info.py)
to check that the options are read in correctly has been added.
This test has a few faults:
A) It does not allow strict library checks as that can be
_very_ system dependent.
B) It compiles some simple C-programs but does currently not link
them to a shared library.
C) As such the test does not check that the flags are actually used.
To circumvent this one should:
A) Make a library of the compiled sources.
B) Check that a runtime_library_dirs is working by checking
with ldd
C) Make a preprocessor flag to check the output of two commands which
should differ according to the flags in each block
I am not too much into the distutils compiler suite. So I have not
endeavoured on this path.
- The current test shows that the flags are read in by the standard system_info
object and can thus be considered a "stable" solution.
- Added note of the 1.10 release schedule.
- Corrected the site.cfg.example, added runtime_library_dirs to
the OpenBLAS example where it seems appropriate.
- Bugfix for the site.cfg.example (the [DEFAULT] block should be
name [ALL])
This might have lead to some confusion, but many of the libraries
are linked explicitly by their own sections, hence it might not have
been caught.
|
| |
|
|
|
| |
Added MKL settings for Intel Fortran Composer.
In addition, changed link to ConfigParser documentation.
|
| |
|
|
|
| |
their presence in site.cfg is only for the benefit of third party
packages using numpy.distutils
|
| | |
|
| |
|
|
|
|
|
| |
Fixes #654 by not fixing it; I don't think NumPy *can* actually fix
the problem as it's a design flaw in Python's multiprocessing. Listed
various alternatives (Python 3.4 forkserver, single-threaded OpenBLAS,
Python threading).
|
| | |
|
| |
|
|
|
|
|
| |
blas_opt and lapack_opt sections are not actually read by the
numpy.distutils.system_info machinery. They are just meta entry points for the
`get_info` public function that in turns introspec the atlas, openblas and mkl
sections.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
2.6.
|
| | |
|
| |
|
|
| |
help automatic installation where one can't edit the source checkout. I've added the alternate name to make it hidden because that's just considerate.
|
| | |
|
| | |
|
| |
|
