When using Qt 5.15.0 or above together with Ninja, check that touching
a source file of a dependency does not needlessly re-run AUTOMOC for
the dependee target.
The AutoMoc timestamp creating custom command explicitly depended
on all dependencies of the origin target (associated to the AutoGen
target).
When an origin target depended on a shared library 'libfoo.so',
if it was re-linked, the AutoMoc custom command would touch its
output timestamp file, and thus cause needless rebuilding of sources,
despite the shared library not having any influence on the AutoMoc
generated files.
Introduce a new '<target>_autogen_timestamp_deps' utility target,
which will serve as an 'order-only' dependency for the custom command.
This will prevent needless rebuilding, because touching 'libfoo.so'
will not cause the custom command to be re-executed.
The new AutoMoc dependency tree looks like:
'_autogen_timestamp_deps (serves as order-only dep)'
<- '<target_autogen>/timestamp' file ( + moc deps file)
<- '<target>_autogen' target.
Fixes: #21020
In commit 99ed39b011 (Ninja Multi-Config: Make link response files
per-config, 2020-07-15, v3.17.4~3^2), we added the target directory to
the response file under the mistaken assumption that two different
targets with the same name could be in different directories. However,
this causes the path to the response file to be too long to fit on a
command line. Take the path back out, while leaving in the per-config
split.
Fixes: #21050
Refactoring in commit 889a7146ff (GoogleTestAddTests: Refactor into
callable method, 2020-03-16, v3.18.0-rc1~450^2~3) accidentally
parsed `TEST_EXECUTOR` as a single-value argument instead of a list.
Previously we disallowed use of arbitrary properties on INTERFACE
libraries. The goal was to future-proof projects using them by not
allowing properties to be set that may affect their future inclusion in
the generated buildsystem. In order to prepare to actually include
INTERFACE libraries in the generated buildsystem, drop the filter and
allow arbitrary properties to be set.
Issue: #19145
Move documentation on IMPORTED INTERFACE libraries to the main section
on Imported Libraries. Revise the section to clarify the different
kinds of imported libraries that can be created and what properties they
need.
Issue: #18975
When a CUDA sdk doesn't have nvcc, defer to the existence of
a version.txt file. When we do this fall back we also reconstruct
the CUDA version via version.txt
Fixes#20643
Repeated invocations of `cmake ... -DCMAKE_C_COMPILER=gcc` should not
trigger a "You have changed variables" message even though the cache
value of CMAKE_C_COMPILER changes from '/path/to/gcc' to 'gcc'.
Make repeated invocations of `cmake ... -DCMAKE_C_COMPILER=gcc;-pipe`
not trigger the warning by comparing the compiler name portion of the list to
the compiler being used.
When using `cmake ... -DCMAKE_C_COMPILER=gcc;-pipe` first invocation of
CMake worked correctly.
When using `cmake ... -DCMAKE_C_COMPILER=/path/to/gcc;-pipe` first
invocation of CMake detected a change to CMAKE_C_COMPILER, printed "You
have changed variables" message, and re-ran the initial compiler tests
after configuration was complete and before generation of the project
files.
The difference was due to the cache being forced updated with the new
value of CMAKE_C_COMPILER so that the comparison check passes.
bd0d03386b cmComputeComponentGraph: Move work out of constructor into Compute() method
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5079
Brad King