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
Setting `CMAKE_INSTALL_NAME_DIR` or the `INSTALL_NAME_DIR` on Swift
targets had no effect when CMP0157 was set to `NEW`. This was a result
of missing the `<TARGET_INSTALLNAME_DIR>` before the `<TARGET_SONAME>`.
Fix that and add a test to verify that the install name directory is
included in the install name.
Fixes: #26175
Skip the `CMAKE_OSX_ARCHITECTURES` validation added by commit db409e5e68
(APPLE: Check if compilers respect CMAKE_OSX_ARCHITECTURES, 2024-05-04,
v3.30.0-rc1~15^2) if the value contains a placeholder, since we do not
know the real value.
Fixes: #26128
Move Git-dependent test cases added by commit 2ef3bd9186
(ExternalProject: Add TLS version options for https connections,
2024-02-26, v3.30.0-rc1~471^2) into the block of cases that run only
when Git is found.
Fixes: #26104
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.
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.
This allows particular frameworks to be targeted by
particular dependencies, and for empty dependency
groups to satisfy NuGet's framework-matching
requirements.
Projects may be generating a list of files or directories to pass as arguments
to file(TOUCH), file(TOUCH_NOCREATE), or file(MAKE_DIRECTORY). Those
lists might end up being empty, so rather than requiring at least one item,
allow an empty list.
Fixes: #24897
The file(MAKE_DIRECTORY) implementation checks whether a path is
allowed to be written to before it checks if it already exists. For the
scenario where a SOURCE_DIR is an existing directory within the main
project's source directory, this triggers a fatal error if
CMAKE_DISABLE_SOURCE_CHANGES is set to true for ExternalProject,
and some FetchContent scenarios. Therefore, add an explicit check for
existence first to avoid making such error-triggering calls.
Fixes: #21872
FETCHCONTENT_FULLY_DISCONNECTED should only be set to true if
each dependency's source directory has already been populated.
Previously, this wasn't being checked, but now it is (subject to a new
policy).
Place `.swiftmodule` files a subdirectory named after the configuration.
Fixes: #25864Fixes: #25997
- Swift/RunCMakeTest.cmake:
- CMP0157-OLD was enabled for Xcode, where it works.
- A test was added that verifies .swiftmodule's are generated into
separate directories with multi-config generators.
- Tests/SwiftOnly/CMakeLists.txt: tests were added that validate that
cross-subdirectory module dependencies (via target_link_libraries)
work.
Also factor out testing that's common across Xcode and Ninja.* generators.
- Ninja expected output files were extended to accept directories named
after the configuration in paths.
- Tests that previously ran with Ninja were allowed to run with Ninja
Multi-Config.
- Swift/RunCMakeTest.cmake:
- Checks for conditions where little or no testing could be done
were moved to the top of the file, with return()s to limit nesting
of the remainder of the code ("Early bailouts").
- CMP0157 tests, which were being performed for all generators, were
factored out into a block at the top of the file.
- RunCMake_TEST_OPTIONS is set initially for all multi-config
generators and list(APPEND)'ed-to in each block() where it was previously
set() and unset().
0dbf2c24bf Tests/RunCMake: Document how to write multi-step test cases
61a08b0856 Tests/RunCMake: Document commands/variables available to RunCMakeTest scripts
aebf6b8b29 Tests/RunCMake: Clarify documentation of platform-specific output matching
c2f8a6729f Tests/RunCMake: Rename "sub-test" terminology to "case"
0add7a802f Tests/RunCMake: Organize README as multiple sections
aff4dc47c4 Tests/RunCMake: Cross-reference README from main Tests/README
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9548
af81b8667e GenEx: Add generator expr. for CMAKE_<LANG>_COMPILER_FRONTEND_VARIANT
8a11a39c51 Help: Use correct programming language names in docs of generator expr.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9538
Verify that `execute_process` launches processes on Windows such that
`GetStartupInfoW` in the child does not populate `STARTUPINFOW` members
reserved for the MSVC C run-time.
Issue: #25996
