In preparation of support of genex $<LINK_LIBRARY:...>, propagate
cmComputeLinkDepends::LinkEntry instances to ensure to have, when needed,
all attributes attached to the link item.
9a48012f93 Configure CMake itself with policies through CMake 3.22
a5a9687799 export: Increase maximum policy version in exported files to 3.22
a9ffded98c Add deprecation warnings for policies CMP0097 and below
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !6948
The previous wording could be misread as ensuring the arguments to the
call match the release version. Clarify that one needs to remove the
call and replace it with the literal release version string.
This was accidentally left out of commit 736663deed (Begin 3.23 release
versioning, 2022-02-03). The step is documented as part of the release
branching process in the CMake Maintainer Guide `Help/dev/maint.rst`.
Avoid looking up the PCH create/use flags just to map them through
flag tables back to the `.vcxproj` settings. Instead, simply
generate the PCH settings directly for each source file.
Since commit 9df1f33c9a (VisualStudio: move PCH rules to projects when
possible., 2020-10-15, v3.20.0-rc1~638^2) we already do this for the
target-wide PCH settings.
The files generatd by `install(EXPORT)` and `export()` commands
are known to work with policies as of CMake 3.22, so enable them
in sufficiently new CMake versions.
The OLD behaviors of all policies are deprecated, but only by
documentation. Add an explicit deprecation diagnostic for policies
introduced in CMake 3.16 and below to encourage projects to port
away from setting policies to OLD.
In commit fc3a1cbdd8 (CompilerID: Compiler extensions default detection,
2021-05-29, v3.22.0-rc1~52^2~2), extensions were assumed to be `OFF`
for Clang targeting the MSVC ABI. However, the `clang` and `clang++`
tools both seem to have extensions enabled by default even when
targeting the MSVC ABI.
This can be observed with the `RunCMake.CompileFeatures` test.
It fails with the GNU-like `clang/clang++` front-end, but removing
the above special case makes it pass. The test passes either way
with the MSVC-like `clang-cl` front-end.
040c509bce gitlab-ci: clarify name of windows fragment for building with ninja
bd14f07ce9 Tests: Skip Clang PCH_INSTANTIATE_TEMPLATES test in MSVC ABI
c26b064b8c Tests: Suppress MSVC CRT deprecation warnings in pseudo_llvm-rc
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6947
040c509bce gitlab-ci: clarify name of windows fragment for building with ninja
bd14f07ce9 Tests: Skip Clang PCH_INSTANTIATE_TEMPLATES test in MSVC ABI
c26b064b8c Tests: Suppress MSVC CRT deprecation warnings in pseudo_llvm-rc
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6947
This brings the patch step into line with all the others which already
had their own `USES_TERMINAL_<step>` keyword. All steps (including
patch) already have their own `LOG_<step>` keyword too, so the lack of
`USES_TERMINAL_PATCH` was inconsistent.
Marc Chevrier