39cbbb59a5 ninja: add experimental infrastructure to generate gcc-format modmap files
791b4d26d6 ninja: add experimental infrastructure to generate modmap files with dyndep
4b23359117 ninja: Add experimental infrastructure for C++20 module dependency scanning
f814d3b3c6 cmNinjaTargetGenerator: use $OBJ_FILE for the object
b0fc2993e1 Treat the '.mpp' file extension as C++ code
988f997100 cmScanDepFormat: Fix name of our internal tool in parse errors
dacd93a2db ninja: De-duplicate version numbers required for ninja features
533386ca29 cmStandardLevelResolver: Factor out helper to capture stoi exceptions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ben Boeckel <ben.boeckel@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Acked-by: Shannon Booth <shannon.ml.booth@gmail.com>
Merge-request: !5562
2e4cbaa521 cmake-gui: Add a Qt version control variable
b3ee09290b cmake-gui: Conditionally switch between QDirModel and QFileSystemModel
020b2766f3 cmake-gui: Replace obsolete QDirModel with QFileSystemModel
684dcdbc5b cmake-gui: Prefer local variable for Qt major version
50fcc94bc5 cmake-gui: Support installation for both Qt5 and Qt6 plugins
2a2942a42e cmake-gui: Use a consistent Qt major version variable name
035078d847 cmake-gui: Remove explicit locale setup
f1de6f6682 cmake-gui: Support building against Qt6
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5621
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
Extend Qt(4|5)Autogen.RerunMocBasic to check the following situation:
Class MyObject3 is a QObject-derived class without Q_OBJECT macro.
It's declared in myobject3.h that is not included by any file that is
input of AutoMoc (this is why we had to add PlainObject).
If myobject3.h were included by main.cpp, then AutoMoc would already
track this dependency, because main.cpp has a Q_OBJECT macro.
After the initial build(s), the Q_OBJECT macro is added to myobject3.h,
and an incremental build is run. With Qt >= 5.15 and Ninja, the build
fails, because AutoMoc is not run due to the missing dependency to
myobject3.h.
Test that removing / adding a Q_OBJECT macro doesn't break incremental
builds.
This was initially done to test the fix for #21620, but the test passes
without the fix. The reason is that test1.h is included by main.cpp, which
contains a Q_OBJECT macro, meaning that test1.h is in AutoMoc's
dependencies transitively.
In a subsequent patch we want to extend RerunMocBasic to test the
removal and addition of Q_OBJECT macros works when building
incrementally.
For that, properly generated dependencies are necessary. Currently, the
MocBasic test project is configured using try_compile, and that turns
off the generation of depfiles.
Replace the try_compile call with execute_command calls that first
configure and then build the test project.
The new target property `EXPORT_COMPILE_COMMANDS` associated with the
existing global variable can be used to optionally configure targets for
their compile commands to be exported.
Fixes: #19462
The scan step may need to output additional information for the
compiler, not just the build tool. The modmap is assumed to be beside
the object output. Additional refactoring may open up a channel to
inform per-source paths to the dyndep rule in the future, but is not
done here.
Optionally enable this infrastructure through an undocumented
`CMAKE_EXPERIMENTAL_CXX_MODULE_DYNDEP` variable. Currently this is
experimental and intended for use by compiler writers to implement their
scanning tools. Warn as such when the feature is activated. Later when
compilers provide the needed scanning tools we can enable this variable
from our corresponding compiler information modules. It is never meant
to be set by project code.
When enabled, generate a build graph similar to what we use for Fortran
module dependencies. There are some differences needed because we can
scan dependencies without explicit preprocessing, and can directly
compile the original source afterward.
Co-Author: Ben Boeckel <ben.boeckel@kitware.com>
Anakin Skywalker