D16032: Generate all kdebugsettings .categories files automatically

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D16032#341315 <https://phabricator.kde.org/D16032#341315>, @apol wrote:
  
  > In D16032#340778 <https://phabricator.kde.org/D16032#340778>, @kossebau wrote:
  >
  > > In D16032#340668 <https://phabricator.kde.org/D16032#340668>, @apol wrote:
  > >
  > > > Considering we're doing our own macro, we can be also more succint. I don't see why we can't have `declare_plugin_qt_logging_category(targetname)`
  > > >
  > > > You can use `target_sources()` instead of adding it to the variable.
  > >
  > >
  > > You mentioned something about target in an earlier comment. But I still have no idea what you mean here and what should be generated how, could you please give an explicit example, to help aligning my brain with yours? :)
  >
  >
  > Does that make sense to you?
  
  
  <snip sample>
  
  Ah , thanks, now I see, you meant the //plugin// target :)
   There is one blocker for this: some plugins share the generated debug.h and debug.cpp files between the actual plugin and some tests. In those cases adding the generated sources to the plugin target does not work (grep for "_LOG_" to find those places). I very much agree though that ideally all plugins should be made consistent here.
  
  > Could possibly be called from `kdevplatform_add_plugin`.
  
  Yes, that should make things more simple & consistent.
  
  Please bear with this patch: its whole idea was to add the , not to fix the complete current logging category situation :)
  Let's fix things step-by-step.

INLINE COMMENTS

> kfunk wrote in KDevelopMacrosInternal.cmake:143
> Any reason this is `macro()`? Could be a `function()`, no?

Macro, because we want to change a variable from the calling scope (the one whose name we get by `_sources`, which is passed on to `ecm_qt_declare_logging_category` which is the one actually going to change the very variable.)

> kfunk wrote in KDevelopMacrosInternal.cmake:143
> Way too much code duplication in all those `declare_*_qt_logging_category` calls, IMO... But I realize that if you want to keep `_declare_qt_logging_category` KDevelop-agnostic (for possible future upstreaming to ECM...) there's no way around this.
> 
> If you don't want to keep `_declare_qt_logging_category` KDevelop-agnostic you could add a `TYPE` argument to it and set some defaults for the different `ARGS_*` based on `TYPE`  instead. Thinking this out further, we wouldn't even need different `declare_*_qt_logging_category`functions, but just use a `declare_qt_logging_category` function with a `TYPE` parameter directly. Just specifiy `TYPE ...` at the call-site in the individual CMakeLists.txt files...

The TYPE seems a nice idea to save on the implementation side, will give a try.

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D16032

To: kossebau, #kdevelop
Cc: kfunk, apol, kdevelop-devel, glebaccon, antismap, iodelay, vbspam, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20181011/13f52810/attachment-0001.html>