Since commit a90d2a9eed (IntelLLVM: Add support for Intel LLVM-based
compilers, 2020-11-02, v3.20.0-rc1~89^2~20), our IntelLLVM compiler
support populates `CMAKE_Fortran_COMPILER_FRONTEND_VARIANT`. However,
the frontend variant was not stored in `CMakeCompilerFortran.cmake`.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
The Intel compiler (pre-LLVM) expected xilink.exe and had special logic to
set xilink.exe. The newer LLVM-based compiler does not want xilink.exe.
link.exe works better for host code, and is the default, so change
the matching condition such that the old compiler matches (and gets
xilink.exe) and the new compiler gets the default link.exe it expects.
A better solution will be to use the compiler as the linker. A future
change will switch to compiler as linker by default, but that fix needs
more validation.
Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
The `-pthread` flag tells the compiler/linker to link to additional
libraries needed for thread support (e.g. libatomic on riscv64). The
flag therefore should be used if requested using
`THREADS_PREFER_PTHREAD_FLAG` also when the pthread functions are
found in libc.
4707ecbe6f CUDA: Support CMP0105 on Clang
15fde4c420 CUDA: Use local shorthands for variables in Clang device link code
cf7e68087d CUDA: Avoid unnecessary allocation and GetLinkLanguage()
5b0693411e CUDA: Ignore USE_WATCOM_QUOTE for device link rules
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6709
Add link flags during the "device compile" step.
Enabled the relevant tests. The disable reasons regarding separable compilation
were outdated and the actual failure case was device link flags support.
Add fields to the VS generator to select a target framework.
Migrate the existing default for VS 12 .NET CF for Windows CE.
Report the values in `CMAKE_VS_*` variables and use them for
the CSharp compiler id project too.
Issue: #22849
This CPack generator was never documented, and has been deprecated since
commit 2ed00e8ef8 (CPack: Deprecate OSXX11 generator, 2020-01-31,
v3.17.0-rc1~45^2).
Issue: #20235
The module was added in CMake 3.18 by commit af96c0f4fa
(CheckLinkerFlag: Add module to check validity of linker flags,
2020-05-16, v3.18.0-rc1~103^2), but it is still possible for projects to
use it without setting policies to the 3.18 version level.
247f1149e1 FindHDF5: clear language-specific libraries list before discovery
f56963cf05 FindHDF5: clear library output variables at the top of the module
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6698
247f1149e1 FindHDF5: clear language-specific libraries list before discovery
f56963cf05 FindHDF5: clear library output variables at the top of the module
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6698
Extend the logic from commit 08c5b3eff0 (GNUtoMS: Add search path for VS
2019 environment scripts, 2020-01-09, v3.16.3~15^2) to consider VS 2022
paths too.
Fixes: #22847
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
c5cc4ddac4 MSVC: Add support for C17
6561b032bc MSVC: Tolerate c_std_17 and c_std_23 features on older compiler versions
22f804e0ec MSVC: Refactor C compile features table for C90, C99, and C11
Acked-by: Kitware Robot <kwrobot@kitware.com>
Reviewed-by: Raul Tambre <raul@tambre.ee>
Merge-request: !6677
MSVC `cl` versions prior to 19.27 had no `-std:c*` flags for C
standards. List the `c_std_{17,23}` features anyway. This allows
projects to at least attempt compilation with these compilers since they
do not have any modes.
The custom "no modes" `cmake_record_c_compile_features` implementation
should only be used in `cl` versions prior to 19.27 because they had no
`-std:c*` flags for C standards. For 19.27 we need a different custom
implementation to account for partial C11 support. For 19.28 and above
we can use the default implementation through the `*__HAS_FULL_SUPPORT`
settings.
We already use this pattern in the MSVC C++ compile feature table.
