The placeholders for `CONFIGURATION` and `EFFECTIVE_PLATFORM_NAME` need
to be handled in the `WORKING_DIRECTORY` of custom commands just as we
already do for the `COMMAND`.
Fixes: #21483
cfce067b3f Tests: Add RunCMake.Make case for conflicting Makefile names
378c047ae3 Makefiles: Explicitly tell 'make' tool what Makefile name to use
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5509
c00a6d3967 MSVC: Do not add /GR to CMAKE_CXX_FLAGS by default
6114c8e994 MSVC: Factor out initialization of /GR flag
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5508
The `/GR` flag has been on by default since MSVC cl 14.0 from VS 2005.
Remove it from the default flags to make it easier for projects to pass
`/GR-` themselves to turn it off.
Projects may be using string processing to replace `/GR` with another
flag, so we cannot simply drop it. Add a policy to drop it in a
compatible way.
Fixes: #21428
1. Set CMAKE_FIND_ROOT_PATH unconditionally.
Revise the implementation from commit a7f41a7ee4 (Android: Fix find_*
search order within NDK for unified toolchains, 2020-10-13). In the old
implementation, if people set CMAKE_FIND_ROOT_PATH, CMAKE_ANDROID_NDK
won't be added to find root. And all paths added to CMAKE_SYSTEM_*_PATH
below will be rerooted to the user specified root.
2. Add api level specific library path to CMAKE_SYSTEM_PREFIX_PATH.
As the discussion in [1], some people want the paths added by
UnixPaths.cmake. They install their libraries according to
GNUInstallDirs [2].
As a result, we cannot clear CMAKE_SYSTEM_PREFIX_PATH. It includes /usr
so no matter what we specify in CMAKE_SYSTEM_LIBRARY_PATH,
/usr/lib/<arch> will be searched first.
The author also pointed out a way to solve this issue [3]. In addition
to other paths, CMake also searches <root>/<prefix> [4]. So we can add
the API specific lib path to the beginning of CMAKE_SYSTEM_PREFIX_PATH,
to have it searched first.
[1] https://android-review.googlesource.com/c/platform/ndk/+/1486800
[2] https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html
[3] https://github.com/android/ndk/issues/1179#issuecomment-613435081
[4] https://gitlab.kitware.com/cmake/cmake/-/blob/11425041f04fd0945480b8f9e9933d1549b93981/Source/cmSearchPath.cxx#L202
a61007b3b0 Tests: Add RunCMake.GNUInstallDirs case for get_absolute_install_dir
229b5ee994 GNUInstallDirs: Add dir argument to GNUInstallDirs_get_absolute_install_dir
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5450
The CustomCommandGenerator `debug-in-release-graph-clean` case actually
cleans using the Debug graph. This is intentional in order to test
cleaning only the Debug parts, so fix the test name rather than changing
what graph it uses.
If --preset is specified with no path argument, use the current
directory as the source directory, the preset's binaryDir as the
binary directory, and don't issue the standard warning for no path
specified.
Fixes: #21386
The old `check_X_source_runs` modules did not verify the arguments, so
we cannot start doing it now. Downgrade the hard error introduced in
commit 357e2ef429 (CheckSoureRuns: Add a unified way to check if a
source runs, 2020-09-14) via !5223 into a noisy warning.
In the following scenario (with 3.18 policies):
1. A CXX target is created.
2. CUDA language is enabled.
CMake 3.18 introduced CMP0104, which requires CUDA_ARCHITECTURES to be
set. Because the CXX target was created before CUDA was enabled it
wouldn't have it set. The Visual Studio generator would however end up
computing CUDA compile options for the CXX target, which would result in
a fatal error due to the policy violation.
There doesn't seem to be a reason to do this for targets that don't
actually use the CUDA language, so we can skip and generate the CXX
target just fine.
Fixes: #21341
Brad King