CMake 3.18 added the first support for any compiler for 17 and 20,
but those were recognized as valid values in earlier CMake versions
even though there was no compiler that supported them. Make this
distinction clear to avoid creating the impression that these standards
could be usefully used before CMake 3.18.
While 98 is recognized as a valid value, it also just gets treated as 03
internally. Document this behavior as well.
Fixes: #22711
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.
Generator expressions in a non-cross custom command's `COMMAND`
arguments are evaluated in the command config. Target-level
dependencies implied by `TARGET_FILE` must therefore be cross
dependencies. This is important to generate proper target-level
dependencies on the cross-config build statements for the target to
which the custom command is attached.
Fixes: #22855
In commit 7abc3d61ac (Ninja Multi-Config: Fix issue with framework
dependencies and Autogen, 2020-02-13, v3.17.0-rc2~18^2) the `cmLinkItem`
comparison operator was updated to order identical strings by the
cross-config boolean. We need to order identical targets that way too
in order to represent both a cross and non-cross dependency on the same
target.
Issue: #22855
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
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
Explain that this represents the compiler's default and mustn't be modified
by the user. Clarify when it's used as the default.
Additionally:
* Add a reference to it in cmake-compile-features in text explaining the
feature.
* Add explanations for the default initialization by
`CMAKE_<LANG>_EXTENSIONS_DEFAULT` to all `<LANG>_EXTENSIONS` pages and
references to CMP0128.
* Slightly reduce the wordiness of the default initialization explanations by
removing an unnecessary "it is".
Fixes#22828.
9c4d6404eb Tests/Environment: also test modifying ambient values
7d52d48a32 cmCTestRunTest: get the default value from the environment
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6682
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
This only works due to some assumptions about how the `ENVIRONMENT`
property is processed. Comments have been added to notify anyone
modifying the behavior about where to look.
Fixes: #22819
Support for `CMAKE_GENERATOR_INSTANCE` was added in CMake 3.11, but the
possibility was mentioned in a comment in older versions, so the wrong
versionadded value was used in commit c43e845d09 (Help: Add `..
versionadded` directives to generator docs, 2020-11-11,
v3.20.0-rc1~476^2).
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.
Craig Scott