`try_compile` and `try_run` now automatically log checks using them to
`CMakeConfigureLog.yaml`.
Add `LOG_DESCRIPTION` arguments to some `try_compile` calls to
replace the description previously written to the old logs.
Issue: #23200
Modify some additional modules that ship with CMake to use the new
SOURCES_FROM_* arguments to try_compile / try_run as added by commits
cb14ae2b87 (try_compile: Add SOURCE_FROM_{ARG,VAR}, 2022-09-21) and
611d801790 (try_compile: Add SOURCE_FROM_FILE, 2022-09-22). This covers
modules that need to read and alter a template source file, which were
not addressed in the previous commit.
Note that FindOpenACC.cmake does not actually need configure_file
functionality; it appears to have inherited the (gratuitous) use thereof
from FindOpenMP.cmake, with which its code bears significant similarity.
Modify most of the modules that ship with CMake to use the new
try_compile / try_run signatures added by commit aa9220d3a0
(try_compile: Add keyword-dispatched signature, 2022-09-02). This
improves debugging by each invocation using its own directory so that
the results of multiple invocations can be retained.
This does not cover any invocations which provide an entire project, as
that flavor of try_compile has not yet been updated.
In commit 0723b2c935 (MPI: Add fallback detection code for MPI when cross
compiling, 2021-09-17, v3.22.0-rc1~89^2) the FindPkgConfig module was
included directly. This produces warnings like:
The package name passed to `find_package_handle_standard_args` (PkgConfig)
does not match the name of the calling package (MPI).
Use `find_package(PkgConfig)` instead, as other find modules do.
Fixes: #22823
The MPI libraries use a compiler wrapper to automatically inject
required flags and libraries into the compiler argument list. However,
the wrapper does not support cross-compiling: the wrapper will try to
invoke the native compiler which cannot handle the cross architecture
MPI libraries and fail.
This MR adds some fallback code for this case, which tries to bypass the
faulty wrapper and determine the necessary flags and libraries directly
from the MPI pkg-config files. The patch tries to be as unintrusive as
possible and should not break any existing use-cases.
Fixes: #22650
MPICH 3.4.2 now reports `-framework OpenCL` as one of its compilation
flag. The compile flag extraction is seeing it as a generic `-f` flag
and misses its argument. This ends up with a compile option of
`-framework` which eats the next flag (and may be very important).
It does not seem that passing `-framework` as a link flag is necessary
at this time, so that is being actively ignored for now.
Fixes: #22555
Cray traditionally does not ship mpicc/mpic++ compiler wrappers.
Due to that, the traditional CMake logic to find MPI is to *only*
support MPI on Cray systems if either
1. Cray Wrappers are used for compiling, or
2. an auxiliary MPI executable is found.
On many new Exascale prototypes, using the Cray wrappers for develop
work is extremely painful. Vendors such as AMD and integrators such
as HPE seem not to go well in lock-step in Cray programming envs,
making offloading with Cray wrappers too challenging. On the other
hand, using the working experimental Vendor compilers works well,
as long as one does not need MPI.
Extend the fallback MPI search logic by also interrogating the
CC/cc/ftn binaries if found for their MPI flags. This does not
change existing logic, i.e. using the Cray wrappers directly, but
provides an additional way to get MPI programs compiled on Cray.
Fixes: #22368
Express the cache entry with `option()`. In combination with policies
CMP0077 and CMP0102, this allows project code to control the switch with
a variable:
```
set(MPI_CXX_SKIP_MPICXX TRUE)
find_package(MPI COMPONENTS CXX)
```
In pure C/CXX projects, when doing an optional search for C/CXX
MPI APIs, I keep getting a reason appended of the form:
```
-- Could NOT find MPI_C (missing: MPI_C_LIB_NAMES MPI_C_HEADER_DIR MPI_C_WORKS)
-- Could NOT find MPI_CXX (missing: MPI_CXX_LIB_NAMES MPI_CXX_HEADER_DIR MPI_CXX_WORKS)
-- Could NOT find MPI (missing: MPI_C_FOUND MPI_CXX_FOUND)
Reason given by package: MPI component 'Fortran' was requested, but language Fortran is not enabled.
```
The reason makes no sense since I did not request Fortran and thus
confuses the reader. It is now only added if the component was truly
requested.
Fix a regression with MPI and CUDA<10.2 that did let `-pthread` flags
slip to nvcc again. In commit b725a19072 (FindMPI: Deny -fexceptions
from NVCC, 2020-07-02, v3.18.0-rc4~12^2) we accidentally forgot to use
the variable containing the replacement result.
Fixes: #21108
Currently CMake passes `-Xcompiler -pthread` flags to CUDA compilers
irrespective of the actual CUDA compiler ID. This makes sure the
additional `-Xcompiler` flag is only used with nvcc.
b4d5ea8233 FindMPI: Preserve order of include directories on re-runs of CMake
8261ee3a9c FindMPI: Restore re-construction of include directories
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4341
The fix in commit 5861c6d450 (FindMPI: Preserve include order when
extracting component directories, 2019-12-19) only works on the first
run of CMake in which we find MPI. Extend the fix to save the compiler
wrapper's entire include path in our cache without splitting anything
out. That way we can preserve the order when CMake re-runs.
Fixes: #20338
The fix in commit 5861c6d450 (FindMPI: Preserve include order when
extracting component directories, 2019-12-19) only works on the first
run of CMake in which we find MPI. It preserves the include directories
on the first run but still splits them up and saves the pieces in the
cache. On future runs the pieces are not re-assembled, and we do not
know the order anyway.
Restore the re-assembly step so that at least all the include dirs are
available. Leave preservation of the original order to later work.
Issue: #20338
The change in commit 5861c6d450 (FindMPI: Preserve include order when
extracting component directories, 2019-12-19) converted a CMake-language
function to a macro. However, it contains a `return()` call that now
applies in the caller's scope, which is in correct. The `return()` is
meant to skip work when using a MPI compiler wrapper as the main
compiler. Move that condition to the call site instead.
Fixes: #20234
Previously, if a CMake project requests a component for a language that is
not enabled, it would simply give an error with the message
Could NOT find MPI (missing: MPI_${LANG}_FOUND)
which is not indicative that the language was not enabled. This change
provides an error message indicating that it failed to find the
particular MPI component because no compiler was available for the
language and the language might need to be enabled for the project.
Closes: #19996
In commit e374b9f1eb (FindMPI: Restore MPI_<LANG>_COMPILE_FLAGS as a
command-line string, 2018-09-10, v3.12.3~6^2) we tried to restore the
compile flags but accidentally inverted the arguments to `list(JOIN)`
causing both `MPI_<LANG>_COMPILE_FLAGS` and `MPI_<LANG>_COMPILE_OPTIONS`
to be empty.
Issue: #18349
In commit f7eaa342de (FindMPI: Store imported target link flags as a
list instead of a string, 2019-06-14, v3.15.0-rc2~2^2) we used
`separate_arguments` to parse the extracted link flags and add them to
`INTERFACE_LINK_LIBRARIES`. That property is not meant for link flags
and CMake may de-duplicate them. This is particularly problematic for
flags like `-Wl,-rpath -Wl,/path1 -Wl,-rpath -Wl,/path2`.
In commit 39c572c9c9 (FindMPI: Updated to use INTERFACE_LINK_OPTIONS,
2019-06-24) we moved the parsed flags over to `INTERFACE_LINK_OPTIONS`,
but that may still perform de-duplication. Avoid the parsing and
de-duplication of flags by passing the original string via `SHELL:`
instead.
Fixes: #19516
Add the `${MPI_EXECUTABLE_SUFFIX}` to each of the items in the
`_MPI_${id}_${LANG}_COMPILER_NAMES` and `_MPI_${LANG}_GENERIC_COMPILER_NAMES` rather
than just adding the suffix to the last item in each list.
