The change in commit 86ad7cc886 (project: Only define non-cache vars if
already defined, 2024-09-15, v3.30.4~2^2) was meant to only check for
non-cache variables when deciding whether to set non-cache project
variables for the current call. However, it erroneously checked for any
variable, including cache variables. This gives the intended result on
the first run, but on subsequent runs a cache variable will exist that
did not on the first run, leading to different behavior between the two
runs. Fix the logic to only check for a pre-existing non-cache
variable, as was originally intended.
Fixes: #26355
In c1ece78d11 (project: non cache <project> prefix variables are
also created, 2024-08-27), we started explicitly setting the non-cache
variable for <projectName>_SOURCE_DIR, <projectName>_BINARY_DIR,
and <projectName>_IS_TOP_LEVEL in addition to setting them as
cache variables. This changed the behavior when a project name
was used more than once, and the second project call happens in
the same scope or a child scope of the first. Previously, the first
project call would set cache variables, and the second project call
would not overwrite those cache variables. With the change in
c1ece78d11, after the second project call the non-cache variables
would mask the cache variables and the project code would see
a different value to what it did before.
Setting the non-cache variable was added to handle the case where
a call to FetchContent_MakeAvailable() would set some non-cache
variables, and it just so happened those matched the same cache
variables that the project() command would set in the project being
fetched. The fetched project would then see a different set of
project-specific variables compared to when it was built standalone.
This commit here narrows the change from c1ece78d11 such that
the non-cache variable is only set by project() if there was already
a non-cache variable set. This still fixes the motivating problem
c1ece78d11 was intended to solve, but it avoids changing the variable
values seen by a project that re-uses the same project name in related scopes.
Issue: #26243, #25714Fixes: #26281
"Console" unexpectedly matches the reserved name regex. This revealed
that `cmCPackNSISGenerator::CreateComponentDescription()` needs to use
the name returned by `GetSanitizedDirOrFileName()` for the component
file glob.
Fix the change from commit a1af593291 (CPack: Support arbitrary
component name when packaging, 2024-05-01, v3.30.0-rc1~151^2~1) to
address these issues and add related checks to the `CPackNSISGenerator`
test case.
Issue: #23612
If CMake is linked to a system-provided curl shared library, the version
at run-time may not match the `LIBCURL_VERSION` at build time. Look up
the run-time curl version to populate the User-Agent string.
This is particularly important since commit d3cbee99e3 (macOS: Prefer
building with system-provided curl, 2024-05-09, v3.30.0-rc1~130^2~1)
switched to building our official binaries on macOS against the system
provided curl shared library.
Fixes: #26209
First, use `cmGeneratedFileStream` to avoid touching an existing file
unless its contents change and to get atomic replacement. Also add a
scope to ensure that the file is in place (at `fout`'s destructor)
before doing anything with the packaging scripts.
See: https://discourse.cmake.org/t/1773
Since commit 67de5b7b82 (VS: Suppress MSBuild default settings affected
by UseDebugLibraries, 2024-02-13, v3.30.0-rc1~538^2~1) we generate an
empty `Optimization` element for the host compiler when there are no C
or C++ optimization flags enabled. The CUDA Toolkit Visual Studio
integration fails with an error if an empty string is inherited from the
host compiler's `Optimization` element. If no CUDA optimization flags
are specified, write an explicit empty `Optimization` element for the
CUDA compiler too.
Fixes: #26144
Since commit d3cbee99e3 (macOS: Prefer building with system-provided
curl, 2024-05-09, v3.30.0-rc1~130^2~1) CMake uses the macOS-provided
curl, which uses the LibreSSL backend by default. This exposes us to
curl issue 12525, created and fixed by the following upstream curl
commits:
* commit `bec0c5bbf` (openssl: switch to modern init for
LibreSSL 2.7.0+, 2023-08-07, `curl-8_3_0~201`)
* commit `9f2d2290d` (openssl: re-match LibreSSL deinit with init,
2023-12-15, `curl-8_6_0~219`)
Work around the bug by preferring the secure-transport backend by
default on the problematic versions of curl.
Since commit c16acd35b3 (GenEx: Add support for custom transitive link
properties, 2024-05-09, v3.30.0-rc1~82^2) evaluation of
`TRANSITIVE_LINK_PROPERTIES` by `install(EXPORT)` enables discovery of
missing dependencies on INTERFACE libraries that we did not previously
diagnose. This regressed existing projects that relied on such
non-diagnosis. Although commit 2fc9e482a9 (Evaluation of
TRANSITIVE_LINK_PROPERTIES isn't considered a usage, 2024-07-05) fixed
this, it also made a significant change to the `UseTo` infrastructure
that may have other subtle effects. Replace the fix with an approach
that explicitly models suppression of the relevant diagnostics.
Fixes: #26108
Starting with VS 17.10 the v143 toolset reserves versions `14.30`
through `14.49`. This is the first time that the first three digits of
the version do not match the toolset name. Extend the special case from
commit d256581bb0 (VS: Fix '-T version=14.40' under VS 17.10 preview 1,
2024-02-19, v3.29.0-rc2~10^2) to cover the entire reserved version range.
The `GoogleTest` module needs this to pass the `TEST_EXECUTOR`
definition to its `GoogleTestAddTests.cmake` helper script in
the `POST_BUILD` command since commit f875c479f5 (GoogleTest: Honor
TEST_LAUNCHER in gtest_discover_tests, 2024-01-17, v3.29.0-rc1~34^2).
Previously it worked only if other characters, such as spaces,
caused the argument to be quoted. This was exposed by running the
`RunCMake.GoogleTest` test in a path without spaces.
Reported-by: Garrett Campbell <gcampbell@microsoft.com>
Remove the stdio handle inheritance suppression originally added by
commit f262298bb0 (... do not inherit pipes in child procs for ctest so
it can kill them, 2007-09-11, v2.6.0~1136). It's not clear what problem
it was trying to solve, was only done in `ctest` and not `cmake`, and
since commit 9c3ffe2474 (BUG: fix problem with stdout and stderr not
showing up in ms dos shells, 2007-09-25, v2.6.0~1066) has not been done
in `ctest` launched under interactive consoles.
Furthermore, the code has been spuriously breaking stdio when `ctest` is
started with both stdout and stderr connected to the same pipe, such as
when `ctest --launch` is used under `ninja`. This is because it used
`DuplicateHandle` with `DUPLICATE_CLOSE_SOURCE` on the stdout handle and
then the stderr handle. If the handles are the same, then the stderr
handle becomes invalid in between these operations, leading to
likely-undefined behavior. Since commit 96b3dd329e
(cmCTestLaunchReporter: Replace cmsysProcess with cmUVProcessChain,
2023-07-26, v3.28.0-rc1~138^2~2) this became more noticeable because
`uv_spawn` performs additional verification on stdio handles.
This could be fixed by instead suppressing inheritance via
SetHandleInformation(h, HANDLE_FLAG_INHERIT, 0);
However, the functionality no longer seems necessary, so remove it.
Set the close-on-exec flag to prevent the jobserver FIFO file
descriptor from leaking to subprocesses spawned by `ctest`.
This leak is usually harmless, but can cause `make test -jN` to hang
at the end of the build if a test leaves a background process running
with the jobserver FIFO file descriptor open.
Fixes: #26027
Brad King