When `Visual Studio` and `Xcode` generators are used, directory for depfile
is not implicitely created by CMake when OUTFILE_DIR option is used.
Fixes: #22932
The Makefile generators use an internal `cmake -E cmake_copy_f90_mod`
tool to avoid rebuilding module consumers when the `.mod` content
changes only in a trivial way (e.g. the time it was built). This is
done with logic specific to each vendor's module file format. Enable
the "Intel" format support when using the IntelLLVM compiler (ifx) too.
Issue: #22922
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>
This generator expression does not report the locations of `.dll`
files on imported targets with the `UNKNWON` type, since their
`IMPORTED_LOCATION` refers to the import library and not the DLL.
Fixes: #22845
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
Since commit cf82300a63 (BinUtils: Clarify search logic and make it more
consistent, 2021-05-27, v3.21.0-rc1~119^2~2) we correctly prefer the
more-specific name `llvm-strip` over `strip` when using Clang. However,
`llvm-strip` from Clang versions prior to 11 require extra flags to
strip everything. Until our `install(TARGETS)` logic learns to add
those flags, avoid using older versions of `llvm-strip` by default.
Fixes: #22785
Since CMake's default compiler flags with MSVC include `-DWIN32` for
historical reasons, a few preprocessor conditions were accidentally
checking for `WIN32` instead of `_WIN32`. The corresponding blocks
were left out when compiling official binaries for `cmake.org` because
we hard-code compiler flags without `-DWIN32`.
Fixes: #22764
VS 2022 Preview 5 renamed the redist directories from `Microsoft.VC142.*`
to `Microsoft.VC143.*` in order to match the `v143` toolset name.
Fixes: #22586
Revert commit 798c1c3192 (GNUInstallDirs: Comply with Debian Policy on
LIBEXECDIR, 2020-10-08, v3.19.0-rc1~11^2).
The Debian Policy builds upon FHS 3.0 and permits installing to
`/usr/libexec`. While Policy does grant an additional exception for
applications to use a single subdirectory of `/usr/lib/<triplet>`, this
is not meant to replace `/usr/libexec` as valid target.
Fixes: #22731
In commit 3aaf1d91bf (MSVC: C++20 final flag, C++23 support, 2021-05-29,
v3.20.4~7^2~1) we forgot to add `cxx_std_23` to the fallback table for
MSVC versions from VS 2010 through VS 2015. This allows project to at
least attempt compilation with these compilers since they do not have
any modes.
Issue: #22729