dbdca56555 Help: CPack/NuGet avoid deprecated variables in the usage example
d06a39dd59 Help: CPack/NuGet add `:Supported:` to some variables
a6a8212ba2 Help: CPack/NuGet add description to the added variables
039bf0f3f3 Help: CPack/NuGet fix `versionadded` position
391e339926 Help: CPack/NuGet add deprecation notes according to the current spec
4e11de312b Help: Reorder variables as they mentioned in the official spec
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9605
6636b11997 Help: Minor grammar and formatting cleanup
c2390f7676 Help: Fix nuget example with unwanted comment and bad use of rst link
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9600
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.
In `Tests/RunCMake/LinkerSelection`, Xcode 16 warns when building the
AppleClassic case:
ld: warning: -ld_classic is deprecated and will be removed
in a future release
Tolerate all build warnings.
9299cbbdb4 FetchContent: Force cmake --fresh to re-execute direct population steps
e82e2c38c1 Tests: RunCMake.FetchContent should not always force _deps removal
f97b25ec4b Tests: Fix -direct variants of FetchContent tests using wrong files
11b684c449 FetchContent: Fix typos in stamp/step file names
a02eec4a9f FetchContent,ExternalProject: Fix extra semicolons in step commands
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9589
This applies a similar modernization as was done in 1ff41ba26e
(Auxiliary: bash-completion: use _comp_initialize, 2024-06-02)
for the cmake executable. The _init_completion function was
deprecated upstream in bash-completion 2.12.
To properly test some functionality, tests may rely on not clearing
things like time stamps between cmake invocations. The RunCMake
infrastructure clears the build directory by default anyway, and
tests may individually ask for that to be disabled where needed.
The line being removed here was originally added to assist with
manually re-running individual tests locally outside the control of
RunCMake. That is no longer appropriate.
The -direct variants of the RunCMake.FetchContent tests were
meant to be using the same result, stdout and stderr files as the
non-direct tests. The -direct tests were specified in the wrong way
for that and ended up using no files at all, so they weren't testing
the full set of expected conditions. Use the test variant feature
provided by the RunCMake infrastructure instead, which is the
proper way to handle this sort of scenario.
Brad King