kossebau added a comment.
In https://phabricator.kde.org/D9334#180540, @ngraham wrote: > We have a report in the wild that this broke compiling KWin with CMake 3.10.x for someone on Gentoo: https://bugs.kde.org/show_bug.cgi?id=387983 Actually did it uncover some issue in kwinscripts code. Which had both a `K_PLUGIN_FACTORY_DECLARATION(KcmKWinScriptsFactory)` (in a file which also had a `#include "module.moc"`) and a `K_PLUGIN_FACTORY(KcmKWinScriptsFactory [...])` (in a file which had no such `#include "main.moc"`). Remember that `K_PLUGIN_FACTORY` covers both definition and declaration, so we had some duplicated declaration where only one is needed. Milian fixed that today by dropping the duplicated K_PLUGIN_FACTORY_DECLARATION and adding a main.moc include (actually could also have removed the module.moc, no longer needed). In https://phabricator.kde.org/D9334#180830, @mpyne wrote: > In fact this appears to force files containing `K_PLUGIN_FACTORY*` into being evaluated by CMake's AUTOMOC (other warning fixes removed files from consideration by CMake AUTOMOC). > > CMake itself appears to have had an interface change for AUTOMOC between 3.8 and 3.9+. > > In particular, https://cmake.org/cmake/help/v3.8/manual/cmake-qt.7.html#automoc > > > If the macro is found in a C++ implementation file, the moc output will be put into a file named according to <basename>.moc, following the Qt conventions. The moc file may be included by the user in the C++ implementation file with a preprocessor #include. If it is not so included, it will be added to a separate file which is compiled into the target. > > vs. https://cmake.org/cmake/help/v3.9/manual/cmake-qt.7.html#automoc > > > If the macro is found in a C++ implementation file, the moc output will be put into a file named according to <basename>.moc, following the Qt conventions. The <basename>.moc must be included by the user in the C++ implementation file with a preprocessor #include. Not sure if this is a behavioural change, or rather a fix in the docu: unless I missed something, the code in the moc file has to see (or rather the compiler compiling it) the declaration of the class with the Q_OBJECT macro, as it contains the definition of declarations done by the Q_OBJECT macro. And if the macro is used for a declaration in a cpp file, the moc file cannot include the cpp file (otherwise the cpp definition content would be compiled 2x), so it has to be rather the cpp file which explicitely includes the moc file (after the code with the class with the Q_OBJECT declaration). > I'm not sure what the right answer is, or whether `K_PLUGIN_FACTORY` needs its output to be run through `moc` but if we do need `moc` to run then I'm not sure what's the best way to address the CMake behavior change for .cpp files. Now, `K_PLUGIN_FACTORY` includes both the declaration (with the Q_OBJECT macro) and the definition. Which is also why it needs to be into a cpp file (unless the header is included only once). And moc needs to run the file which has K_PLUGIN_FACTORY, as it needs to create the implementation as declared from the contained Q_OBJECT macro. And put the generated code into a file. Which itself needs to be then pulled into the very cpp file with the K_PLUGIN_FACTORY,, due to the need to see the declaration, as said above. So IMHO things are okayish as they are now and should not have really changed, besides just being less tolerant to doubled class declaration code as in kwinscripts. Which itself is questionable. automoc in the end will stay a poor beast. It is run before the buildsystem has been created and dependencies are known, yet has to have an idea how to parse the code (despite include dirs yet unknown) to find out what classes to generate code for and how to add to the build (automoc.cpp files or the explicitly included files). The day will be great when moc no longer is needed :) REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D9334 To: mlaurent, dfaure Cc: kossebau, mpyne, ngraham, #frameworks
