Print an error message for invalid values of
`CTEST_CUSTOM_TEST_OUTPUT_TRUNCATION` in a ctest dashboard script.
The option was added by commit 140704d443 (ctest: add option for
output truncation, 2022-03-07, v3.24.0-rc1~513^2).
Fixes: #23869
We've made several attempts to add a dummy symbol to `mocs_compilation.cpp`
when there are no automoc sources:
* commit 4a9daae483 (automoc: silence linker warning on macos,
2022-05-25, v3.24.0-rc1~55^2)
* commit 844244ccdc (automoc: avoid compiler warnings in linker-warning-
silencing code, 2022-08-10, v3.24.1~6^2)
* commit fc8628389f (automoc: avoid more compiler warnings in linker-
warning-silencing code, 2022-08-29)
The last attempt derives a symbol name from the path to the source
file, but that breaks reproducible builds because it is not stable
w.r.t. the location of the build tree. Revert all these attempts
for the 3.24 release series, and return to what 3.23 and below did.
Further investigation will be needed to resolve the original issue.
Fixes: #23937
Issue: #23551, #23823, #23823
Refactoring in commit a2cfa2da4f (GenEx/LINK_LIBRARY: Add features for
framework support on Apple, 2022-02-10, v3.24.0-rc1~661^2) accidentally
removed a `GetParentDirectory` call. Restore it.
Fixes: #23891
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
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
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
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
febe3190f0 Merge branch 'backport-3.23-cmake-P-path-args'
846a650ff7 cmake: In -P mode ignore extra paths on the command line
c362cba566 cmake: simplify to a single source of truth of working mode
261fa5db39 cmake: In -P mode ignore extra paths on the command line
314135cdf1 cmake: simplify to a single source of truth of working mode
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !7494
Revert commit a334f1b906 (VS: Write ZERO_CHECK.proj for VS19 and above,
2021-12-24, v3.24.0-rc1~607^2) and a supporting change from
commit 7219988b00 (VS: Exclude ZERO_CHECK.proj from .sln for
include_external_msproject, 2022-07-15, v3.24.0-rc4~1^2).
The change was made to support `dotnet` tooling in addition to
`msbuild`. However, not having `ZERO_CHECK` in the `.sln` breaks common
interactive workflows. Revert the change for now. Later it can be
re-introduced behind some kind of option that enables `dotnet` support.
Fixes: #23726
Issue: #20227
Revert commit 10668f26c9 (AUTOUIC: Fix internal paths of generated
ui_foo.h files, 2022-05-21, v3.24.0-rc3~20^2). It broke some existing
projects that use more than one `.ui` file of the same name.
Fixes: #23759
Issue: #23523
In `cmGlobalVisualStudio7Generator::WriteTargetsToSolution`, we skip
writing `ZERO_CHECK.proj` to solution file as the check in
`cmGlobalVisualStudioGenerator::IsInSolution` returns `false` for
`ZERO_CHECK`. However, we write ZERO_CHECK to ProjectDependencies for
external projects as there are no checks in
`cmGlobalVisualStudio71Generator::WriteExternalProject`.
Similar to `cmGlobalVisualStudioGenerator::IsInSolution`, we introduce
`IsDepInSolution(const std::string&)` which excludes `ZERO_CHECK.proj`
from being added to sln file for the cases where we have `ZERO_CHECK.proj`.
Fixes: #23708
If we're creating generation objects for imported targets only, we
don't need the export sets. Only compute build file generators
if generating for all targets.
Fixes: #23709
Marc Chevrier