build
Details
Diff Detail
- Repository
- R241 KIO
- Branch
- fix_cmake_warning
- Lint
No Linters Available - Unit
No Unit Test Coverage
Why not do this in ECM?
This comment seems to come from KDE apps or something, which depend on old ECM. But KF5.42 depends on ECM5.42, so I don't see the usefulness.
Ok I can move it to ecm (mais in which file ?) "kde-modules/KDECMakeSettings.cmake" ?
and it depends if apps have some specific macro for example in kmail we have "EXPORT_KONTACT_PLUGIN" too
@flherne has been working on a patch to add
list(APPEND CMAKE_AUTOMOC_MACRO_NAMES "K_PLUGIN_FACTORY_WITH_JSON")
to KF5CoreAddonsConfig.cmake and similar for other modules., so the needed settings are automatically injected into the builds that use components which provide such Q_OBJECT embedding macros. Seems life kept him busy so he did not yet upload that for review?
Doing this in ECM would mean maintaining a list of macros in a repo/product separate from the repo/products where the respective macros are defined. More, what libraries should ECM cover? Just KF5 ones? What about macros from libs from kde apps, extragear etc.
It scales better, is better to maintain and feels also more logic to have each module's cmake config inject any needed extension of CMAKE_AUTOMOC_MACRO_NAMES into the build of products linking and picking up any such cpp macros. That's what cmake config is for, configuring and providing things as needed with a dep, no? :)
Edit: of course if the macro is used in the repo itself as well, there is setting CMAKE_AUTOMOC_MACRO_NAMES needed both in the CMakeLists.txt and in the installed cmake config file. Not perfect, but still better IMHO over a separate to maintain list in ECM.