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>
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
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
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
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.
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 commit 6051a49c78 (Visual Studio: Add Android support, 2020-06-12,
v3.19.0-rc1~619^2) we run MSBuild to build a sample project to detect
the sysroot. Previously we relied on `CMAKE_VS_MSBUILD_COMMAND` being
available. That required commit d5b5c19278 (cmGlobalGenerator:
FindMakeProgram() before CMakeDetermineSystem, 2020-06-15,
v3.19.0-rc1~619^2~3) to make it available early enough. However, that
ordering broke `CMAKE_GENERATOR_INSTANCE` so we need to prepare to
revert it. Use `cmake_host_system_information` to get the location of
MSBuild under a VS generator instead.
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
3add62462c Xcode: Fix detection of default language standard when given -std= flags
5c4424e5b7 CMakeDetermineCompilerId: Tolerate variables named for languages
Acked-by: Kitware Robot <kwrobot@kitware.com>
Reviewed-by: Raul Tambre <raul@tambre.ee>
Merge-request: !6598
If one uses `CFLAGS='-std=...'` or `CXXFLAGS='-std=...'` then the given
`-std=` flag(s) will always be used. That effectively changes the
compiler default standard level and extension settings. Fix the
Xcode generator's compiler id logic to preserve any `-std=` flag
so that the proper defaults are detected.
This problem was exposed by commit 4a0485be7f (cmStandardLevelResolver:
Avoid unnecessary flags, fix unset level logic, 2021-05-29), which
changed the logic to not pass any `-std=` flag if the standard level
and extension settings requested by the project match the default
(`stdIt <= defaultStdIt` became `stdIt < defaultStdIt`). The new
logic assumes the detected default standard matches what will actually
happen when the project is generated.
