The redundant `cmake_autogen` process execution was optimized for
non-`CROSS_CONFIGS` usage. It was executed three times for each
config although only one of them is needed.
7bf4e30090 Autogen: Default AUTOGEN_USE_SYSTEM_INCLUDE to ON if it is not set
033dc7ee2f Autogen: Add AUTOGEN_USE_SYSTEM_INCLUDE target property
8ba16db163 Tests/RunCMake: Add option for dynamic expected output
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8400
`AUTOGEN_USE_SYSTEM_INCLUDE` was added. `AUTOGEN_USE_SYSTEM_INCLUDE`
is a boolean property that can be set on a target to indicate that the
autogen target include directory should be added as a system include
directory or normal include directory to the target.
Add this target property to specify macro names that propagate to
dependents as `AUTOMOC_MACRO_NAMES`. The dependents will automatically
generate MOC files for source files that contain the inherited macro
names.
Co-Authored-By: Craig Scott <craig.scott@crascit.com>
Fixes: #19679
Generate `moc_predef.h` using the same C++ standard level that will be
used to compile the target so that the compiler's predefined macros can
be more accurately recovered.
Fixes: #24624
Qt-Issue: https://bugreports.qt.io/browse/QTBUG-110847
Refactoring in commit d867e05892 (Autogen: Use JSON instead of CMake
script for info files, 2019-09-20, v3.16.0-rc1~57^2) broke support for
numerical values of `AUTOGEN_PARALLEL`. Parse and verify the range.
Warn if the value is invalid.
Fixes: #20376
Many custom commands are created by CMake itself rather than by
the user. These custom commands should always have their policies
set to NEW, and user-created custom commands should have their
policy values set only from the state snapshot. In addition, we
want to genericize the mechanism of recording a policy at the time
of custom command creation.
Add a CM_FOR_EACH_CUSTOM_COMMAND_POLICY macro to genericize
custom command policies. Use this to define all custom command
policies. Make all such policies NEW instead of WARN by default.
Remove individual policy modifier methods and add a single method
that records relevant values from a cmStateSnapshot. Remove the
no longer needed explicit policy settings from synthesized custom
commands.
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
