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
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
If a target doesn't have any source files, fall back to the global
list of enabled languages to determine the language of the header
file to verify.
Fixes: #23774
We use the host machine's architecture to select the `MSBuild.exe`
binary variant, and the host toolset architecture. When CMake is
compiled as `x64` or `x86` it may still run on ARM64 hosts. Detect the
actual architecture of the host at runtime instead of relying on the
architecture of CMake's own binary.
The `arm64/MSBuild.exe` executable is an ARM64 .NET 4 application, which
requires the ARM64 version of .NET Framework 4.8.1 to be installed on
the machine. That version is not yet released for Windows 10; however,
the `MSBuild/Current/Bin/arm64` directory is still created when
installing Visual Studio 2022 (a user may upgrade to Windows 11 later).
Use it only if the .NET Framework is installed.
The `amd64/MSBuild.exe` executable cannot run on Windows 10 ARM64,
but can run on Windows 11 ARM64.
Fixes: #23755
Brad King