Some systems set CMAKE_SYSTEM_PROGRAM_PATH, which pollutes the
environment for this test. Erase it before executing the test to get
a clean environment.
Fixes: #23300
Revise the test from commit 08db1341a6 (find_*: ensure consistent
behavior for cache variables, 2021-05-03, v3.21.0-rc1~177^2) to avoid
searching outside the test directories.
Fixes: #23299
9fb1dff070 LINK_LIBRARY: Add features for library support on Apple
93a153bc7f Genx-LINK_LIBRARY: simplify framework features definitions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7029
Since commit 880ca66b51 (Fix: `while()` can silently ignore incorrect
condition, 2021-08-09, v3.22.0-rc1~238^2~4) we correctly reject the
code
set(paren "(")
while(${paren})
endwhile()
However, rejecting it breaks compatibility with projects that used such
code accidentally. In CMake 3.21 and below, any error in the condition
was ignored because the `false` result exited the loop first. Restore
tolerance of the error for now. A policy will be needed to make it an
error later.
Note that the same condition with `if` was always correctly rejected.
Fixes: #22524
Issue: #23296
Co-authored-by: Brad King <brad.king@kitware.com>
dae3ad08fa Tests: Add cases for CMAKE_CUDA_ARCHITECTURES={all,all-major}
5c1f5357b0 VS: Fix CUDA compiler id with CMAKE_CUDA_ARCHITECTURES={all,all-major}
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7035
dae3ad08fa Tests: Add cases for CMAKE_CUDA_ARCHITECTURES={all,all-major}
5c1f5357b0 VS: Fix CUDA compiler id with CMAKE_CUDA_ARCHITECTURES={all,all-major}
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7035
The `CudaOnly.All` test only sets these in project code after CUDA is
enabled. Add another case to test the values during compiler detection.
Issue: #23161
Encourage placing preset includes near the beginning of a preset
file and ensure the example shows that usage. Move the prose
discussing includes to its own section to improve discoverability
and break up paragraphs to make each main point harder to miss.
Also clarify ${sourceDir} to remove any ambiguity with regard to
its meaning in included files.
Issue: #23214
d33b12d84b Add support for build tree symlink inside source tree
43416c48ed cmOutputConverter: Always set relative path top source and binary together
de766bc7e0 Xcode: Fix support for source tree symlink inside build tree
55db2cf1e5 Makefiles: Fix "make depend" with add_custom_command DEPFILE
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !7020
0a81ea1f12 Genex-LINK_GROUP: Add possibility to group libraries at link step
a9928eb4a5 SunPro C: ensure LINKER: prefix is usable for all versions
01ff75b2ff cmComputeDepends::LinkEntry: introduce enum to specify item type
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7005
Since commit c564a3e3ff (Ninja: Always compile sources using absolute
paths, 2021-05-19, v3.21.0-rc1~129^2), both the Ninja and Makefile
generators pass source files and include directories to the compiler as
absolute paths. However, in some other contexts within generated build
systems, we generate paths that may be relative or absolute. In these
contexts, we prefer relative paths, but avoid them when they contain a
`../` sequence that leaves both the build tree and the source tree:
* When the build tree is outside of the source tree, all paths to the
source tree are absolute.
* When the build tree is inside the source tree, we previously assumed
that it is a real directory such that exiting the build tree with
`../` enters the source tree. This allowed paths to the source
tree to be relative to the build tree.
In the latter case, we previously did not support using a symbolic link
inside the source tree to point at the build tree. This is because
relative paths to the source tree would be generated with `../`
sequences leaving the build tree, but they would jump to the parent of
the real build tree, which is not the source tree.
Fix this by requiring that `../` sequences stay inside the build tree
even if its path appears to be inside the source tree. When the build
tree is inside the source tree, all paths to the source tree are now
absolute. For consistency, this applies regardless of whether the
path to the build tree contains a symbolic link.
Fixes: #21819
Since commit 61495cdaae (Fix Xcode project references to the source
tree, 2009-09-22, v2.8.0~43) we force source file references to use
relative paths from the source tree. If the source tree path is a
symbolic link inside the build tree, the relative `../` sequence
goes to the wrong place. The problem with debug breakpoints motivating
that change does not seem to occur in modern Xcode versions, so update
the logic to use a relative path only when it does not need to start
in any `../` sequence.
This test runs the `Tests/QtAutogen/MocInclude` test inside symlinked
directories. The `MocInclude` test previously relied on
`get_filename_component(... REALPATH)` to get the real source tree
location and compute the path to `AutogenCoreTest.cmake` from it.
However, this does not work on Windows due to issue #17206. The
test has been passing on Windows only on machines where symlinks
cannot be created and the main part of the test is skipped. On
machines where symlinks can be created, the test failed with that
approach. Fix it by explicitly passing the path to the helper
script in as a cache entry. Avoid relying on `REALPATH`.
Brad King