Revert commit 6f17996edc (gitlab-ci: Update Windows builds to MSVC 14.33
toolset, 2022-08-15). A `cmake-gui` built with the MSVC 14.33 toolset
emits spurious errors when configuring CMake projects, even when the
adjacent `cmake` binary succeeds reliably. Revert to the known-working
MSVC 14.32 toolset pending further investigation.
Issue: #23859
Since commit 6e4d20921d (FindVulkan: Add component for `shaderc_combined`,
2022-05-18, v3.24.0-rc1~111^2~5), the module rejects unknown components.
Add a release note about this behavior change.
Issue: #23849
`find_package(Vulkan REQUIRED FATAL_ERROR)` calls exist in the wild, but
`find_package` does not have a `FATAL_ERROR` option. We silently
tolerated such calls prior to commit 6e4d20921d (FindVulkan: Add
component for `shaderc_combined`, 2022-05-18, v3.24.0-rc1~111^2~5), by
treating the argument as a component and ignoring it. Restore tolerance
by removing the component and warning about it.
Fixes: #23849
e9755bc7c1 MinGW: Restore using windres when toolchain-prefixed name is not available
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7574
Since commit 55ba10dcfd (MSYS/MinGW Makefiles: Simplify selection of
windres as Resource Compiler, 2022-05-26, v3.24.0-rc1~82^2) the `MinGW
Makefiles` and `MSYS Makefiles` generators no longer specify the plain
`windres` name for the MinGW resource compiler. Instead, the name is
specified in our MinGW platform information module. After the change in
commit af4adf6aa9 (MinGW: Fix default windres selection when
cross-compiling, 2020-03-25, v3.18.0-rc1~492^2), when cross-compiling,
we only specify the toolchain-prefixed name of the tool, which may not
be available in all environments.
If the toolchain-prefixed name is not available, fall back to the plain
`windres` name. We already use this approach for other binutils.
Fixes: #23841
1cd65dfa0e TI compiler: Add support for COMPILE_WARNING_AS_ERROR target property
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Josef Angstenberger <code@jtxa.de>
Merge-request: !7560
Refactoring in commit 8c65b7042e (cmExportFileGenerator: Simplify
collection of targets missing from export set, 2022-04-11,
v3.24.0-rc1~281^2) accidentally dropped the behavior change from
commit 0ad2a1c181 (Export: Never treat private link libraries as
public package dependencies., 2013-09-24, v3.0.0-rc1~559^2).
Restore the behavior and add a test.
Fixes: #23838
Revise the code added by !7296 (merged).
Make cmake_automoc_silence_linker_warning less warning-y.
Fix weak-tables clang warning and copyable-polymorph clazy warning.
Fixes: #23823
Revise the change from commit fe57410b33 (IPO: Use -flto=auto if
compiler is GCC >= 10.1, 2022-06-22, v3.24.0-rc2~2^2) to require
at least GCC 11 on Windows.
Fixes: #23836
Issue: #23640
Since commit 3257c34073 (FindThreads: avoid failing in AIX when using
-D_XOPEN_SOURCE=500, 2022-04-30, v3.24.0-rc1~197^2) we no longer check
for `pthreads.h` before checking for the `-pthread` flag. Compilers
targeting the MSVC ABI do not have such a flag, so avoid performing the
check unnecessarily.
Fixes: #23829
The CMAKE_VERIFY_INTERFACE_HEADER_SETS variable is intended to
be under the control of the user. It doesn't discriminate between
header sets defined in the main project and those defined by
dependencies brought into the build directly via FetchContent.
Developers will usually only be interested in verifying the main project's
header sets, not those from dependencies.
Make the variable effectively only enable header set verification of the
main project by turning it off during FetchContent_MakeAvailable() calls.
The user still has variables like CMAKE_PROJECT_INCLUDE and
CMAKE_PROJECT_<projectName>_INCLUDE available to them if they
want to enable verification of all or specific dependencies respectively.
Fixes: #23808
Directory-level rules in `CMakeFiles/Makefile2` were previously
previously written by each directory's local generator using its own
decision for using relative or absolute paths.
Since commit d33b12d84b (Add support for build tree symlink inside
source tree, 2022-02-25, v3.24.0-rc1~583^2), each local generator
explicitly models the relationship between its source and build paths,
and uses this to determine when it is safe to use relative paths.
Because `add_subdirectory` supports arbitrary placement of the source
and build directories, different local generators may have different
relationships between their source and build paths. This can cause
disagreement among rules written to `CMakeFiles/Makefile2`.
Restore consistency by always using the root local generator to write
rules to `CMakeFiles/Makefile2`. Relative paths should always be
expressed w.r.t. the top-level build directory since that is the working
directory in which the `make` tool processing the file will run.
Fixes: #23814
Since commit cb811d11ce (Help: Improve description of modules,
2019-04-12, v3.15.0-rc1~210^2) we've had two `::` prompts for
the preformatted block listing the result variables. Convert the
block to a definition list.
Since commit 06c6e76a12 (ci: update to WiX 3.14.0.6526, 2022-06-10,
v3.24.0-rc1~4^2~2) we download the WiX binaries from `wixtoolset.org`
instead of a `github.com` CDN. Avoid hitting their organization site
on every CI job by hosting the binaries at `cmake.org`.
Revert commit 5101d586c4 (Windows: Prefer junctions for directory
symlinks, 2022-02-22, v3.24.0-rc1~575^2). Junctions do not support
`../` and other non-canonical paths. Revert their use pending further
investigation.
Fixes: #23781
Issue: #23257
The docs for the CMAKE_VERIFY_INTERFACE_HEADER_SETS variable do
mention that it initializes the property, but the property docs didn't
mention the variable. Add that missing cross-reference.
When we introduced the `GTest::gmock` and `GTest::gmock_main` targets in
commit 50bf457a0d (FindGTest: Add target for gmock library, 2021-10-17,
v3.23.0-rc1~321^2) we failed to handle the case where GTest isn't found.
Don't construct gmock targets that depend on non-existent gtest targets
when gtest failed to be found.
In c2044fdf3f (FetchContent: Respect the CMP0135 policy setting,
2022-06-02), the URL keyword was wrongly assumed to only have
a single value. Multiple URL values are allowed if they are all
non-local. Rework the logic to remove that incorrect assumption
and handle both single and multi-value URL combinations.
Fixes: #23792
Brad King