summaryrefslogtreecommitdiffstats
path: root/Modules/FindBLAS.cmake
Commit message (Collapse)AuthorAgeFilesLines
* FindBLAS: Consider OpenBLAS with thread libraries only with C or CXXBrad King2019-12-121-2/+6
| | | | | | | | The check added by commit 276b56f01c (FindBLAS: Add second try for OpenBLAS with thread libraries., 2019-06-07, v3.15.0-rc2~5^2) can work only when C or CXX is enabled. Fixes: #20092
* FindBLAS: Add second try for OpenBLAS with thread libraries.Alexander Neumann2019-06-171-1/+15
| | | | Issue: #16221
* FindBLAS: Choose MKL arch based on BLA_VENDORJakub Benda2019-05-161-9/+8
| | | | | | | | | | | | | | | | | | | | | Recently, FindBLAS has been extended with additional library search path based on the environment variable MKLROOT. However, the choice of the Intel MKL architecture (IA-32 vs Intel64) was based on unrelated (and possibly undefined) size of integer. This commit changes the selection of the Intel MKL architecture to instead consider the variable BLA_VENDOR, if available. So, if the environment variable MKLROOT is defined and BLA_VENDOR=Intel10_32, then $ENV{MKLROOT}/lib/ia32_<OS> will be added to the search path (OS = lin, win, or mac). Similarly, if MKLROOT is defined and BLA_VENDOR=Intel10_64lp or BLA_VENDOR=Intel10_64ilp, then the path $ENV{MKLROOT}/intel64_<OS> will be used. If either MKLROOT or BLA_VENDOR is undefined, no additional search path on top of LD_LIBRARY_PATH / DYLD_LIBRARY_PATH / LIB is be added.
* FindBLAS: Use Intel fortran interface on OS X even with GNU FortranJakub Benda2019-05-041-1/+2
| | | | | | | | | | According to Intel MKL Link Line Advisor, there is no GNU Fortran interface library provided for OS X variant of Intel MKL. Because of this missing library, FindBLAS was failing on OS X, looking for nonexistent library libmkl_gf_[i]lp64. To prevent this, FindBLAS will now always use Intel Fortran interface for MKL on OS X (libmkl_intel_[i]lp64), even with GNU Fortran.
* Modules: Update documentation formattingBartosz Kosiorek2019-04-081-7/+7
|
* FindBLAS: respect MKLROOT and MKL_ROOT if availableMario Emmenlauer2019-03-151-0/+26
| | | | Fixes: #19052
* Merge topic 'lapack-docs'Brad King2019-01-311-52/+66
|\ | | | | | | | | | | | | | | | | be7b30f67e Find{BLAS,LAPACK}: Add note and example for using Intel MKL b323407235 Find{BLAS,LAPACK}: Update docs to use modern conventions ba30b94435 FindLAPACK: Remove extra indentation from a line Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !2880
| * Find{BLAS,LAPACK}: Add note and example for using Intel MKLMichael Hirsch, Ph.D2019-01-301-0/+11
| |
| * Find{BLAS,LAPACK}: Update docs to use modern conventionsMichael Hirsch, Ph.D2019-01-301-56/+59
| |
* | Find{BLAS,LAPACK}: Drop unnecessary mark_as_advanced callsBrad King2019-01-311-1/+0
|/ | | | Cache entries created by `try_compile` are already `INTERNAL`.
* Merge topic 'blaslapack_mkl_gfortran'Brad King2018-11-271-44/+63
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | c259912b14 FindBLAS: Do not look for BLAS once BLAS95 has been found d5f691be0b FindLAPACK: Additional libraries for MKL+gfortran combination 8b63265ea5 FindLAPACK: Unify internal variables related to MKL ede1715c1d FindLAPACK: Remove MKL components already provided by MKL BLAS 03879b11af FindLAPACK: Prioritize Intel MKL b4edf7b5d2 FindBLAS: Support 32bit Intel MKL 10.3+ fc149a72f7 FindBLAS: Support combination of gfortran and Intel MKL f0d52f55f1 FindBLAS: Consolidate duplicated code related to MKL on Windows Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !2633
| * FindBLAS: Do not look for BLAS once BLAS95 has been foundJakub Benda2018-11-241-7/+9
| | | | | | | | | | | | When BLA_F95 is ON, FindBLAS looks for BLAS95_LIBRARIES (in Intel MKL). As this is a superset of BLAS_LIBRARIES, if they are found, no further search in other vendors is necessary.
| * FindBLAS: Support 32bit Intel MKL 10.3+Jakub Benda2018-11-181-1/+10
| | | | | | | | | | | | The module FindBLAS now correctly finds Intel MKL distributions that do not have the (long deprecated) library "libguide", but use "libiomp5" instead.
| * FindBLAS: Support combination of gfortran and Intel MKLJakub Benda2018-11-181-24/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The module FindBLAS now correctly chooses MKL BLAS libraries to search, based on the compiler ID. The MKL libraries needed for BLAS functionality are the following: libmkl_{gf|intel}_{lp64|ilp64}.{a|so} libmkl_{gnu|intel}_thread.{a|so} (or libmkl_sequential.{a|so}) libmkl_core.{a|so} libm libdl lib{gomp|iomp5}.{a|so} (only with libmkl_*_thread.*) To achieve the goal, the following internal variables are defined and used: BLAS_mkl_INTFACE = "gf" or "intel" (based on compiler ID) BLAS_mkl_THREADING = "gnu" or "intel" (based on compiler ID) BLAS_mkl_OMP = "gomp" or "iomp5" (based on compiler ID) BLAS_mkl_LM = "-lm" (not set on Windows) BLAS_mkl_DL = "-ldl" (not set on Windows) The default values for the first three of them are "intel" and "iomp5", unless a Fortran compiler is loaded with CMAKE_Fortran_COMPILER_ID equal to "GNU"; in such case the "gf", "gnu" and "gomp" values are used. In non-Windows systems, the thread library as well as libm and libdl are now added to the linker line to allow static linking of libgomp.
| * FindBLAS: Consolidate duplicated code related to MKL on WindowsJakub Benda2018-11-181-12/+7
| | | | | | | | | | The code that decides which library suffix to use for MKL libraries in Windows was in two places. This commit consolidates it in one place.
* | Merge topic 'blas-pkgcfg'Brad King2018-11-201-0/+1
|\ \ | |/ |/| | | | | | | | | a3c31effed FindBLAS: Restore BLAS_FOUND when found using pkgconfig Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !2631
| * FindBLAS: Restore BLAS_FOUND when found using pkgconfigMartin von Gagern2018-11-191-0/+1
| | | | | | | | | | | | Refactoring in commit v3.12.0-rc1~92^2 (FindPkgConfig: export the list of found libraries also as variable, 2018-05-11) dropped use of FPHSA to set `BLAS_FOUND`. Set it explicitly instead.
* | Merge topic 'blaslapack95'Brad King2018-11-061-1/+1
|\ \ | |/ | | | | | | | | | | | | f1a3e4eca8 FindLAPACK: Correct library name and symbol searched in LAPACK95 wrapper 970b18e9a5 FindBLAS: Correct symbol searched in BLAS95 wrapper Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !2560
| * FindBLAS: Correct symbol searched in BLAS95 wrapperJakub Benda2018-11-051-1/+1
| | | | | | | | | | | | | | | | | | The symbol "SGEMM", originally used to determine if a library provides Fortran 95 wrappers for BLAS, has been replaced by "sgemm_f95". "SGEMM" is provided by libmkl_intel_(i)lp64, which does not provide the generic Fortran 95 wrappers. Instead, libmkl_blas95_(i)lp does; one of the specializations of the type-generic interfaces contained in that library is "sgemm_f95".
* | Help: Convert remaining modules to block-style commentsKitware Robot2018-10-221-68/+69
|/
* Find{BLAS,LAPACK}: Find also ILP64 MKL BLAS and LAPACKJakub Benda2018-10-081-19/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | Modern Intel MKL packages offer 64-bit BLAS and LAPACK libraries in any of the eight combinations of the following three binary options: - sequential or threaded - LP64 or ILP64 - static or shared The modules FindBLAS and FindLAPACK did not allow full selection of arbitrary combination; in particular, only LP64 variant was used. The original list of possible BLA_VENDOR values related to MKL, Intel10_64lp Intel10_64lp_seq is thus extended by another pair of "vendors", Intel10_64ilp Intel10_64ilp_seq Depending on the selection, either "_lp64", or "_ilp64" MKL libraries are searched for. Some comments in the two CMake modules were modified to indicate that even though the "vendors" contain the number "10", they also apply to all further versions of MKL.
* FindBLAS: Make Intel MKL the most preferred explicit BLAS library againHubertus van Dam2018-08-301-180/+180
| | | | | | | | | | By adding the "if (NOT BLAS_LIBRARIES)" statement to the Intel MKL detection code block we have unintentionally turned Intel MKL from the most preferred into the least preferred BLAS library. To fix this issue the Intel MKL detection code block needs to be moved forward to make it the first explicit BLAS library we test for. This is change does just that and re-instates Intel MKL as the most preferred explicit BLAS library.
* FindBLAS: Make Intel MKL code block respect prior found BLAS librariesHubertus van Dam2018-08-301-155/+157
| | | | | | | | | | All non-Intel BLAS library detection blocks have an if-statement "if (NOT BLAS_LIBRARIES)" to ensure that if a BLAS library was found we are not going to try and find another one. This causes a problem when we have already found that we do not need to specify a BLAS library, as the Intel MKL library takes precedence over everything. Introducing the "if (NOT BLAS_LIBRARIES)" if-statement fixes this problem.
* FindBLAS: Detect implicitly linked BLAS libraryHubertus van Dam2018-08-301-2/+28
| | | | | | | | Run the Check_Fortran_Libraries macro with an *empty* list of libraries to detect whether the compiler implicitly links BLAS. If this works, set `BLAS_LIBRARIES` to a placeholder value to get through the rest of our logic. At the end replace the placeholder by a real empty string again to report to callers.
* FindBLAS: Re-indent module source code to use normal conventionsKitware Robot2018-08-301-476/+476
|
* FindPkgConfig: export the list of found libraries also as variableRolf Eike Beer2018-05-111-9/+2
|
* FindBLAS: do not write an imported target name into BLAS_LIBRARIESRolf Eike Beer2018-04-241-1/+5
| | | | | | | | | | | Since commit v3.11.0-rc1~177^2 (FindBLAS: optionally query pkg-config for a library, 2017-12-15) the `BLAS_LIBRARIES` result variable may incorrectly contain the name of an imported target. Instead store the list of libraries in the variable. Unfortunately pkg_check_modules does not provide a way to get this so we need to use a (temporary) hack of reading `INTERFACE_LINK_LIBRARIES` from the interface library target. Fixes: #17934
* FindBLAS: optionally query pkg-config for a libraryRolf Eike Beer2017-12-151-0/+19
| | | | | | This is more or less what Gentoo implements for years, but in a more sophisticated version that uses the target mode now offered by pkg_check_modules().
* FindBLAS: simplify if()Rolf Eike Beer2017-12-151-2/+1
|
* FindBLAS: use FPHSARolf Eike Beer2017-12-151-42/+6
|
* Find{BLAS,LAPACK}: Add support for FLAME blis and libflameJ M Dieterich2017-11-161-0/+15
| | | | | | | FLAME (github.com/flame) provides a variety of numerical libraries. `blis` and `libflame` can be setup to expose BLAS/LAPACK interfaces. Fixes: #17470
* FindBLAS/LAPACK: Format documentationGregor Jasny2017-03-221-7/+26
| | | | Closes #16624
* Simplify CMake per-source license noticesBrad King2016-09-271-13/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Per-source copyright/license notice headers that spell out copyright holder names and years are hard to maintain and often out-of-date or plain wrong. Precise contributor information is already maintained automatically by the version control tool. Ultimately it is the receiver of a file who is responsible for determining its licensing status, and per-source notices are merely a convenience. Therefore it is simpler and more accurate for each source to have a generic notice of the license name and references to more detailed information on copyright holders and full license terms. Our `Copyright.txt` file now contains a list of Contributors whose names appeared source-level copyright notices. It also references version control history for more precise information. Therefore we no longer need to spell out the list of Contributors in each source file notice. Replace CMake per-source copyright/license notice headers with a short description of the license and links to `Copyright.txt` and online information available from "https://cmake.org/licensing". The online URL also handles cases of modules being copied out of our source into other projects, so we can drop our notices about replacing links with full license text. Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority of the replacements mechanically. Manually fix up shebang lines and trailing newlines in a few files. Manually update the notices in a few files that the script does not handle.
* Find{BLAS,LAPACK}: Fix when used in pure Fortran projects (#16039)Melven Roehrig-Zoellner2016-04-051-8/+3
| | | | | | Use `CMAKE_<LANG>_COMPILER_LOADED` to detect enabled languages because `if( _LANGUAGES_ MATCHES C )` is always true on Windows as the RC language is activated automatically and matches C.
* Find{BLAS,LAPACK}: Add support for OpenBLAS (#16024)J M Dieterich2016-03-181-3/+17
| | | | OpenBLAS (www.openblas.net) is the successor to GotoBLAS.
* FindBLAS: Fix pattern matching on BLAS vendor nameBrad King2016-01-081-6/+6
| | | | | | | The if(STREQUAL) expressions do not support globbing expressions. Use regular experssions with MATCHES instead. Reported-by: Yahui Wang <youngqv@foxmail.com>
* Replace MATCHES ".+" tests with NOT STREQUAL ""Rolf Eike Beer2014-04-141-1/+1
|
* Remove .* expressions from beginning and end of MATCHES regexsRolf Eike Beer2014-04-141-4/+4
| | | | | | | | | All these expressions work the same: "foo" ".*foo.*" "^.*foo.*$" This assumes that the "Intel*" expressions were meant to be "Intel.*".
* Find*: Make find_package(.. QUIET) affect Check* modules.Clinton Stimpson2014-03-301-0/+4
| | | | | | | | | | Fixes issues #14812 and #14813 where find_package(OpenMP QUIET) and find_package(Qt4 QUIET) would still print out messages when calling check*() functions. Also a partial fix for #14445 where building CMake (without cmake-gui) when Qt5 is installed and Qt4 is not installed and warnings come out of FindQt4.cmake.
* Convert builtin help to reStructuredText source filesKitware Robot2013-10-151-25/+35
| | | | | | | | Run the convert-help.bash script to convert documentation: ./convert-help.bash "/path/to/CMake-build/bin" Then remove it.
* FindBLAS: Fixes for Windows MKL supportLeszek Swirski2013-10-081-12/+86
|
* Find* (and some other): use ${CMAKE_CURRENT_LIST_DIR} in include()Rolf Eike Beer2012-11-041-2/+2
| | | | | | This solves a lots of warnings, e.g. in the FindModulesExecuteAll test. If the installed version on the system is rather old this may even lead to bugs, e.g. https://bugs.gentoo.org/show_bug.cgi?id=436540
* Remove CMake-language block-end command argumentsKitware Robot2012-08-131-73/+73
| | | | | | | | | | | | | | | | | Ancient versions of CMake required else(), endif(), and similar block termination commands to have arguments matching the command starting the block. This is no longer the preferred style. Run the following shell code: for c in else endif endforeach endfunction endmacro endwhile; do echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/' done >convert.sed && git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' | egrep -z -v '^(Utilities/cm|Source/kwsys/)' | egrep -z -v 'Tests/CMakeTests/While-Endwhile-' | xargs -0 sed -i -f convert.sed && rm convert.sed
* Merge topic 'mixed-lib-to-lib64'David Cole2012-08-131-2/+2
|\ | | | | | | | | | | | | | | | | af80da3 remove lib64 Unix paths if the respective lib path is also given 733726e find_library: Fix mixed lib->lib64 (non-)conversion cases (#13419) 54add62 find_library: Simplify lib->lib<arch> expansion 6ca2f82 find_library: Refactor lib->lib64 conversion 1fe4b82 find_library: Add test covering lib->lib64 cases
| * remove lib64 Unix paths if the respective lib path is also givenRolf Eike Beer2012-07-211-2/+2
| | | | | | | | If FIND_LIBRARY_USE_LIB64_PATHS is set both will be searched anyway.
* | Fixed: FindLAPACK does not find MKL 10.3 when using gcc 4.xAlexey Ozeritsky2012-07-181-4/+2
|/
* FindBLAS/FindLAPACK: Work with MKL version 10.3 (#12924, #12925)Alexey Ozeritsky2012-02-161-110/+94
|
* FindBLAS/LAPACK fixesAlexey Ozeritsky2011-09-011-6/+6
| | | | | fixed: CMAKE_FIND_LIBRRAY_SUFFIXES misprint added: ATLAS vendor to FindLAPACK module
* FindBLAS/LAPACK fixesAlexey Ozeritsky2011-08-311-5/+14
| | | | | | | | fixed: saving/changing/restoring CMAKE_FIND_LIBRARY_SUFFIXES variable. fixed: BLA_VENDORs "Apple" (Accelerate Framework) and "NAS" (vecLib Framework) fail as 'cblas_dgemm_' doesn't exist. fixed: improve "Generic" detection on Ubuntu (and I assume Debian) (work with libblas3gf and liblapack3gf packages).
* fixed: search of ATLAS library for C/C++-only projectsAlexey Ozeritsky2011-08-151-3/+3
|
generated by cgit v0.12 at 2024-12-27 11:49:26 (GMT)