Revert commit 10668f26c9 (AUTOUIC: Fix internal paths of generated
ui_foo.h files, 2022-05-21, v3.24.0-rc3~20^2). It broke some existing
projects that use more than one `.ui` file of the same name.
Fixes: #23759
Issue: #23523
For every file foo.ui we generate a ui_foo.h file in
${target}_autogen/include or ${target}_autogen/include_$<CONFIG> in the
multi-config case. Even .ui files in subdirectories are handled this
way. That means, .ui files with the same base name will conflict in a
target.
However, for .ui files in subdirectories we added generated sources with
the nonexistent path ${target}_autogen/include/subdir/ui_foo.h. This
patch fixes that.
Also, CMake will now yield an error if a target has multiple .ui files
with the same base name.
Fixes#23523
For the Ninja generator and targets that have AUTOMOC_BUILD_DIR set, the
AutoMoc target was always out of date.
That was because the depfile in the AutoMoc build directory was
referencing the wrong timestamp file:
target_autogen/timestamp: ...dependencies...
instead of
automoc_build_dir/timestamp: ...dependencies...
Use the relative path of the timestamp file as rule name for the
depfile. That path is calculated with AUTOMOC_BUILD_DIR taken into
account.
Fixes: #23547
We evaluate `LINK_LIBRARIES` and `INTERFACE_LINK_LIBRARIES` for two purposes:
* Constructing the link line.
* Collecting usage requirements.
We evaluate `INTERFACE_LINK_LIBRARIES` separately for each purpose in
order to support the `$<LINK_ONLY:...>` generator expression used to
express private link dependencies of a static library. Previously we
only evaluated `LINK_LIBRARIES` for linking, and used that result for
collecting usage requirements too. Therefore `$<LINK_ONLY:...>` does
not work in `LINK_LIBRARIES`.
With the introduction of `INTERFACE_LINK_LIBRARIES_DIRECT`, evaluation
of `LINK_LIBRARIES` now needs to distinguish these two cases in order to
honor link dependencies encountered through `$<LINK_ONLY:...>` without
also exposing other usage requirements through private dependencies of a
static library. Revise internal infrastructure to distinguish the two
cases when evaluating `LINK_LIBRARIES`. Make the information available
in code paths for `INTERFACE_LINK_LIBRARIES_DIRECT` and `LINK_ONLY`.
Defer actually using the information to later commits.
Issue: #22496
Store the main dependency as the first entry in the dependency list plus
a boolean member indicating its existence. Note that this slightly
changes existing behavior: the main dependency was previously the last
entry of the dependency list.
When there's no moc_predefs.h generated, we add the WIN32 define as
fallback.
Before this change, we added the WIN32 define if the host system was
Windows. That's wrong when cross-compiling. Now we're checking whether
the target system is Windows.
Fixes: #22933
Make `cmCustomCommand` have just only default constructor.
Use each setter instead. This follows the builder pattern.
Introduce `cc::SetOutputs(std::string output)`.
This will be used later, as substitution for `cc::SetOutputs({output})`.
Instead of using the target name directly (which ends up in the `Ninja`
generators querying for the `LOCATION` parameter), wrap up the target
name in a `$<TARGET_LINKER_FILE:>` to avoid the query for the unset
property.
8ff0c2b1dd AutoMoc: Do not list moc macros multiple times
6e2f4029c0 cmAlgorithms: Preserve const-ness in cmRemoveDuplicates range signature
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !6459
When working on a project with a nested dependency tree, a macro
can be added multiple times. For example in a project I am working
on, in the warning "includes the moc file [... ] but does not contain
a [...] macro" the macro list contains 127 entries but only 25 unique
ones.
Revert commit e5ec0e52f4 (AUTOUIC: Fix generating of dependency rules
for UI header files, 2021-07-22, v3.21.1~8^2) because it caused
regressions. For example, changing one C++ source can now cause many
others to rebuild. Revert the change pending further investigation.
Fixes: #22531
Issue: #16776
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
We could not rely on .ui files when generating the ninja rules
for the generated UI header files. .ui files might be added to the
target sources but never processed by AUTOUIC afterward, since UI
header files are never included in a source code. Instead of adding
dependency rules based on the .ui files, this approach scans
non-generated source files for includes of the UI header files,
as AUTOUIC does. This gives the consistent set of UI header files
at configure time, that could be used to generate byproducts rules
for the AUTOUIC. Also, the path to the generated UI header file depends
not on the .ui file location but on the include line is used in source
files.
Fixes: #16776
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
