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.
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.
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
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
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.
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.
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.
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
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".
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.
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.
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.
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.
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
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().
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.
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.
The if(STREQUAL) expressions do not support globbing expressions.
Use regular experssions with MATCHES instead.
Reported-by: Yahui Wang <youngqv@foxmail.com>
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.
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
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
