aebfbcaa46 AutoGen: Use depfiles for the XXX_autogen ninja targets
f765fdea03 AutoGen: Use moc's feature to output dependencies
f8c505d4b3 Add a parser for GCC-style depfiles
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Jan Niklas Hasse <jhasse@bixense.com>
Merge-request: !4221
Extend the fix from commit 0578239d3a (VS: Tell VS 16.4 not to verify
SYMBOLIC custom command outputs, 2019-09-23, v3.15.4~2^2) to apply to
SYMBOLIC *inputs* too. This is needed when there is a chain of custom
commands that use symbolic paths for ordering.
Fixes: #20179
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
The XXX_autogen targets are implemented as utility commands, which
means they always run, even if there weren't any changes.
For the Ninja generator and Qt >= 5.15 we're taking a different
approach: This commit adds custom commands that create
XXX_autogen/timestamp files. Those custom commands have a depfile
assigned that is generated from the depfiles that were created by moc.
The XXX_autogen targets merely wrap the XXX_autogen/timestamp custom
commands.
Fixes: #18749
In Qt version 5.15.0 moc learned to output the dependencies
of the generated file.
This commit enhances JobCompileMocT to read the dependency file
written by moc. The dependencies are stored in the same cache that's
used for the dependencies determined by dependency filters.
The dependency filter functionality is turned off if moc's dependency
output feature is used.
Fixes: #17750Fixes: #19058
Introduce the function cmReadGccDepfile that parses a GCC-style depfile
and returns its content. The implementation uses a lexer that is
modeled after the re2c implementation in Ninja.
The sample files of the autotest have been created with gcc 8.3.0.
This depfile reader is to be used by the Autogen facility to make use
of the depfiles that are generated by Qt's meta object compiler.
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.