ccaa0bccc4 Ninja: Do not clean metadata when re-generating inside a running build
657820a00b Ninja: Track when running to re-generate during a build
b12b013028 Ninja: Factor metadata cleanup into dedicated method
5d92e60d81 Ninja: Skip cleandead and recompact if build.ninja is missing
dd0a4718fd Ninja: Fix CMAKE_NINJA_OUTPUT_PATH_PREFIX with Ninja 1.10
0944caaebb Tests: Fix RunCMake.CMP0037 test with Ninja 1.10
9d4883cce5 Tests: Fix RunCMake.Ninja test for Ninja 1.10
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4290
45d21dd5d4 CUDAToolkit: Use CMAKE_FIND_ROOT_PATH for all sdk lib searches
e357772f20 CUDAToolkit: Use HINTS as it has higher precedence for searches
c6ec51c625 CUDAToolkit: functions names now use CMake's reserved namespace
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4278
When CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY is set on
Xcode generator created post build scripts which tried to call
XCODE_DEPEND_HELPER.make script in subproject.
But XCODE_DEPEND_HELPER.make don't exist in
subprojects when mentioned option is set on.
Fixes: #20262
Fixes#17559
Replace our hard-coded default of cudart=static with a first-class abstraction to select the runtime library from an enumeration of logical names.
When `ninja` re-runs CMake to re-generate the build system, do not try
to use the ninja tools to update metadata on Windows. The outer ninja
process is already holding the files open.
Issue: #20274
The ninja 1.10 tools we use since commit fb18215904 (Ninja: clean ninja
metadata once generated, 2019-05-13) expect `build.ninja` to be
available and loadable. In commit 6cc74b6140 (cmGlobalNinjaGenerator:
avoid cleandead and recompact in Ninja-Multi, 2020-01-22) we added a
condition to exclude the tools in a case where `build.ninja` is not
available. Generalize that condition using a local variable and extend
it for the case that `build.ninja` is not loadable in the current
directory because it is meant to be a sub-ninja for a higher directory.
QCC is a wrapper around GCC, but it is not a fully transparent wrapper.
Some compile options need to be passed to GCC using a `-Wc` option.
QCC does not support --sysroot, so setting CMAKE_SYSROOT in a toolchain
file currently does not work. This means that it is likely that no one
is setting CMAKE_SYSROOT in existing QNC toolchain files. Override the
GCC option for sysroot in the QCC.cmake file with -Wc,-isysroot.
This exposes a further issue in that the QNX SDK does not follow the
same architectural folder structure as linux uses. That is, on linux
systems, architecture-specific libraries might be in
<sysroot>/usr/lib/<arch>
such as
/usr/lib/x86_64-linux-gnu/libcurl.so
CMake models this by suffixing the <arch> onto lib directories when
searching for libraries.
The QNX SDK is structured differently such that the <arch> should be
used as a prefix:
<sysroot>/<arch>/usr/lib
such as
<sysroot>/x86_64/usr/lib/libcurl.so
Add a variable for platform configuration to set whether to prefix or
suffix the <arch> and set that in the QCC.cmake.
Use the directory structure of the QNX SDK to compute the <arch> from
the implicit library directories. The assumption is that the arch will
be a single directory directly below the CMAKE_SYSROOT, below which the
usr/ prefix occurs.
It would not be appropriate to instruct users to make the <arch> part of
the sysroot when specified in the toolchain file because:
1. That would be non-DRY - The QCC wrapper already determines the <arch>
by the -V argument passed to the compiler, specified in the toolchain
file as the CMAKE_C_COMPILER_TARGET variable.
2. The includes in the QNX SDK are not below the <arch> directory.
So, the location of the <arch> in the full path is different on QNX
compared to, say an embedded linux platform, but the intent is the same.
Add documentation to recommend the use of CMAKE_SYSROOT in a QNX
toolchain file.
As the CMAKE_SYSROOT is always the same for QNX, it would be possible to
simply set it in QCC.cmake. However, that would change behavior for
existing users as when CMAKE_SYSROOT is set, files/paths outside of the
CMAKE_SYSROOT do not get found.
The <arch> prefixing is only enabled in cmSearchPath.cxx if
CMAKE_SYSROOT is set. This ensures that the user gets consistency in
the current state without CMAKE_SYSROOT, and gets better consistency
when using CMAKE_SYSROOT.
`clang-tidy` does not infer driver mode if it is not provided with a
JSON compilation database. This is exactly the way cmake launches it.
Hence clang-tidy will only use the default driver mode. Add an explicit
driver mode argument to avoid this.
The CMP0037 OLD and WARN cases that actually use reserved target names
like `all` produce `build.ninja` files with duplicate build statements
producing the same output. With Ninja 1.10 and above we run ninja
tools at the end of generation that require `build.ninja` to be loadable.
It is not loadable for these test cases, so skip them.
With Ninja 1.10 we run the cleandead and recompact tools after
generation. These require that `build.ninja` be loadable. Update the
`CustomCommandJobPool` case to define the referenced job pools to make
`build.ninja` loadable.
