`include-what-you-use` diagnostics, in practice, are specific to
the environment's compiler and standard library. Update includes
to satisfy IWYU for our CI job under Debian 12.
Remove the output file before invoking moc in case the case of source file has
changed on disk. Recent versions of clang warn when the case of the include
directive (which does change) doesn't match the case of the file on disk.
We've made several attempts to add a dummy symbol to `mocs_compilation.cpp`
when there are no automoc sources:
* commit 4a9daae483 (automoc: silence linker warning on macos,
2022-05-25, v3.24.0-rc1~55^2)
* commit 844244ccdc (automoc: avoid compiler warnings in linker-warning-
silencing code, 2022-08-10, v3.24.1~6^2)
* commit fc8628389f (automoc: avoid more compiler warnings in linker-
warning-silencing code, 2022-08-29)
The last attempt derives a symbol name from the path to the source
file, but that breaks reproducible builds because it is not stable
w.r.t. the location of the build tree. Revert all these attempts
for the 3.24 release series, and return to what 3.23 and below did.
Further investigation will be needed to resolve the original issue.
Fixes: #23937
Issue: #23551, #23823, #23823
Revise the code added by !7296 (merged).
Make cmake_automoc_silence_linker_warning less warning-y.
Fix weak-tables clang warning and copyable-polymorph clazy warning.
Fixes: #23823
when an empty `mocs_compilation.cpp` is included in a static library,
the macos linker emits a warning:
```
/Applications/Xcode13.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
file: path/To/Library.a(mocs_compilation.cpp.o) has no symbols
```
we therefore generate a globally visible weak symbol in the form of a
virtual function table
When merging a new set of uic options with a base set of options,
such as when a source file has a non-empty AUTOUIC_OPTIONS
property, the test for whether to support options starting with
two hyphens was only testing if the Qt major version was exactly
5 rather than at least 5. That had the effect of preventing such
options from being merged correctly when using Qt6, so new and
base options would both be present instead of the single merged
option from the source file properties. Update the version check
and rename function arguments to avoid misrepresenting what
they mean.
Note that uic accepts long option names with a single hyphen too.
See Qt docs for QCommandLineParser::ParseAsLongOptions
for confirmation.
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
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
Once the generated UI headers are created by UIC they also are involved
into processing in next run on ninja. Autogen adds `ui_*.h` files to
the deps file `ui_*.h` and this cause timestamp start depend on `ui_*.h`.
Meanwhile `ui_*.h` depend on timestamp because of the explicit rules
added by commit 1265c65b33 (AUTOUIC: Collect ui header files for Ninja
generator, 2021-02-18, v3.21.0-rc1~600^2). Avoid adding `ui_*.h` to
deps file at second ninja run.
Fixes: #16776
cmReadGccDepfile() calls cmSystemTools::CollapseFullPath(), which
is not thread safe due to internal caching. Serialize calls to
cmReadGccDepfile() in autogen to avoid thread safety issues.
Fixes: #22014
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
This fixes the issue when two .ui files have the same name,
but different locations. In this case, Ninja deps file only
contains .ui file that was found first. So <src>/xxx/yyy.ui
and <src>/yyy.ui were processed as a same file by AUTOUIC.
Consider a Qt project with a header file that does not contain the
Q_OBJECT macro. Adding the Q_OBJECT macro is supposed to trigger a run
of moc.
When using Qt >= 5.15 and the Ninja generator, re-running AutoMoc is
controlled by the contents of a Ninja depfile. In the situation above,
AutoMoc would not re-run, because the header/source files without
Q_OBJECT macro are not contained in the depfile.
Add the relevant source files of the project to the merged depfile to
re-run AutoMoc whenever a source file changes.
Fixes: #21620
AutoMoc uses the moc-emitted dependency file of Qt 5.15 to track
dependencies. Such a dependency may well live outside the project and
can vanish, for example when installing a new compiler version.
This situation was detected before, but merely a warning was issued.
Now, we're considering a generated file as out of date if a dependency
is missing and re-generate it.
We also have to remove the missing dependency from the ParseCache.
Otherwise the AUTOMOC target for all generators other than Ninja will
always be out of date.
The ParseCacheChanged flag had to be made atomic, because we're
potentially accessing it from multiple threads. The dependencies vector
itself is not vulnerable in this regard, because there's one vector per
file, and we're accessing exactly one ParseCacheT::FileHandleT per thread.
Fixes: #21136
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
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
The `std::endl` manipulator, except inserting `\n` character, also
performs `os.flush()`, which may lead to undesired effects (like
disk I/O in the middle of forming data strings). For the
`std::stringstream` it also has no meaning.
* replace multiple `operator<<` calls on a string literal w/
the only call and the only (bigger) string literal;
* replace one character string literal used in `operator<<`
w/ a char literal.
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
On Windows, `CollapseFullPath` called with a path that ends with a dot
might return a file with the same base name but any extension.
To make sure we get only the file with the requested header extension,
pass the complete file name to `CollapseFullPath`.
Fixes: #19892
We used to store information for the _autogen target in a CMake script
file AutogenInfo.cmake, which was imported by a temporary cmake instance in
the _autogen target. This introduced the overhead of creating a temporary
cmake instance and inherited the limitations of the CMake language which
only supports lists.
This patch introduces JSON files to pass information to AUTORCC and
autogen_ targets. JSON files are more flexible for passing data, e.g. they
support nested lists.
The patch has the side effects that
- AutogenInfo.cmake is renamed to AutogenInfo.json
- AutogenOldSettings.txt is renamed to AutogenUsed.txt
- RCC<qrcBaseName><checksum>Info.cmake is renamed to
AutoRcc_<qrcBaseName>_<checksum>_Info.json
- RCC<qrcBaseName><checksum>.lock is renamed to
AutoRcc_<qrcBaseName>_<checksum>_Lock.lock
- RCC<qrcBaseName><checksum>Settings.txt is renamed to
AutoRcc_<qrcBaseName>_<checksum>_Used.txt
Provide a standardized way to handle the C++ "standard" headers
customized to be used with current CMake C++ standard constraints.
Offer under directory `cm` headers which can be used as direct
replacements of the standard ones. For example:
#include <cm/string_view>
can be used safely for CMake development in place of the `<string_view>`
standard header.
Fixes: #19491
The new `AUTOMOC_PATH_PREFIX` boolean target property enables automatic
generation of the path prefix `-p` option for `moc`.
`AUTOMOC_PATH_PREFIX` is initialized from the variable
`CMAKE_AUTOMOC_PATH_PREFIX`, which is ON by default.
When `AUTOMOC_PATH_PREFIX` is enabled, CMake tests if a `moc`ed header file is
in one of the include directories. If so, then the `-p` option, with the
relative path of the header parent directory to the respective include
directory, is added to the `moc` command. If the header file is not in an
include directory, the `-p` option is omitted.
Closes: #18815 "AUTOMOC: generated files include full relative path,
breaking certain reproducible builds"
