For an AUTOMOC'ed target foo, when depfiles are used, there are the
following dependencies:
foo_autogen -> foo_autogen/timestamp
foo_autogen/mocs_compilation.cpp -> foo_autogen/timestamp
The first is used to trigger AUTOGEN.
The second erroneously triggers a recompilation of
mocs_compilation.cpp when any source file of target foo is touched.
Remove the latter dependency and replace it with an order-only
dependency from foo_autogen/mocs_compilation.cpp to
foo_autogen_timestamp_deps.
That is achieved by making mocs_compilation.cpp or its
per-configuration variants byproduct(s) of the timestamp file.
Fixes: #22338
Consider the case where the find_package call for QtCore is wrapped in a
function call. Then AutoGen cannot determine the Qt version, because it
only looks at variables and directory properties. The former don't leave
the function scope and the latter are not set by default.
As a fallback, locate the moc executable via its target and call it with
the --version argument to determine the Qt version.
Issue: #22028
This is achieved by adding a rule file which carries the UI files as dependencies but performs no meaningful command. Its output path points to a timestamp file which is instead touched by the pre-build command that runs autogen. The rule file therefore triggers the build if any of the files have been changed more recently than the last autogen run.
Fixes: #17959Fixes: #18741
If the relative path to a UI file was empty then the source group for the corresponding autogen header file would not apply because of a double slash in the path.
339dbc901f Help: Note that CMP0116 is recorded at the time of CC creation
e3740e020e Tests: Test Qt autogen target with CMP0116 set to WARN
cf34011ce7 Tests: Test per-CC behavior of CMP0116
3a95503512 Ninja: Use CMP0116 status recorded at time of custom command's creation
f01f10e8fb cmCustomCommand: Record value of CMP0116 at time of creation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5848
339dbc901f Help: Note that CMP0116 is recorded at the time of CC creation
e3740e020e Tests: Test Qt autogen target with CMP0116 set to WARN
cf34011ce7 Tests: Test per-CC behavior of CMP0116
3a95503512 Ninja: Use CMP0116 status recorded at time of custom command's creation
f01f10e8fb cmCustomCommand: Record value of CMP0116 at time of creation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5848
The '<user target>_autogen/timestamp' target supposed to
generate ui header files using the 'uic'. Ninja must have
information about these header files as a result of generating.
The fix collects .ui files of the user target and generates
a list of the ui headers that need to be added to the generating
results of the '<user target>_autogen/timestamp' target.
The case when the .ui files are not specified and collected by
AUTOUIC from the include directives of the project source files
is not covered in this patch.
Fixes: #16776
Qt6 reads our internal AutogenInfo.json file. In 92d7b456e5
(Autogen: Add support for per-config sources, 2020-10-20), the
ordering of the HEADERS array elements was changed and this
broke their cmake_automoc_parser. We don't need to change the
order of the array elements, we can append to the existing ones
instead. Do this to allow their cmake_automoc_parser to continue
to work.
Fixes: #21823
* Adding implementation for policy CMP0118 being set to `NEW`.
* Adding new tests for policy CMP0118 being set to `NEW`.
* Checking the `GENERATED` property with `get_source_file_property` or
`get_property` now always returns exactly `1` or `0`. No other values
will be returned. Note, that this is a backwards-incompatible change,
even when policy CMP0118 is unset or set to `OLD`.
* Additionally, as `get_source_file_property` and `get_property` now
always check if a source-file was marked globally visible, even when
CMP0118 is unset or set to `OLD`, they possibly return `1` where they
might have returned `0` before the changes introduced by this commit.
Note, that this is a backwards-incompatible change, even when policy
CMP0118 is unset or set to `OLD`.
* As a consequence, the tests for policy CMP0118 being unset or set to
`OLD` got slightly adjusted, too, to reflect these changes in
behavior.
For Qt >= 5.15.0 and Ninja generators AutoMoc creates a depfile to let
Ninja decide when to run AutoMoc. This was introduced by commit aebfbcaa46
(AutoGen: Use depfiles for the XXX_autogen ninja targets, 2020-01-14,
v3.17.0-rc1~58^2).
However, AutoMoc was not triggered after adding a new moc-able file to
the project. This patch adds the project file (and potentially included
files) to the dependencies in the depfile.
Now, a re-run of AutoMoc is triggered if the project file changes.
Fixes: #21127
When building Qt itself, the moc and uic executables are spcecified
via a generator expression of the form $<TARGET_FILE:Qt6::moc>,
which ends populating Moc's and Uic's 'Executable' field but not the
ExecutableTarget and ExecutableTargetName fields.
In such a scenario, the code in
cmQtAutoGenInitializer::InitAutogenTarget fails to add a dependency
on moc (or uic), because ExecutableTarget is null. First try to add
a dependency on the ExecutableTarget if it's not empty, otherwise try
to add a dependency on the path specified in the 'Executable' field.
Issue: #21118
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
Adds a flag to indicate that pipe output from a custom command should be
interpreted as UTF-8 encoded. This change does not introduce a public
way to set the flag, but generators that create internally-generated
commands know if they are calling cmake, which uses UTF-8 pipes.
MSBuild added support for interpreting output of PreBuildEvent,
PreLinkEvent, PostBuildEvent, and CustomBuildStep as UTF-8. This change
will appear in Visual Studio 16.6 Preview 3. It is opt-in, and you need
to add the StdOutEncoding tag. MSBuild treats these as property bags so
if we emit the tag for earlier versions of Visual Studio it would be
safely ignored. This change emits the StdOutEncoding tag and sets it to
UTF-8 whenever the custom command UTF-8 pipe flag is set. This fixes
globalization issues when the output from cmake contained characters
that required MSBuild to interpret as UTF-8 before displaying them.
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
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
