See D27150 as an example next to the test and docs for how this would be used. The ecm_qt_export_logging_category also is kept similar to ecm_qt_declare_logging_category in case someone wants to turn the manual definition to a generated one, that wil just need addition of HEADER and the sources variable and change of macro name called.

BTW, core of this logic has been taken from KDevelop's internal util macros, where this served for some versions already :) https://phabricator.kde.org/source/kdevelop/browse/master/cmake/modules/KDevelopMacrosInternal.cmake though with some additional wrappers for repeated data & patterns.

Seems ok for me

@mlaurent Thanks for review :)
Do you happen to know any more complex usages of ecm_qt_declare_logging_category and/or manual category definitions which can and should be checked for how these new methods would work out?
I have not really researched bigger parts of KDE code for if the currently proposed method calls will be sufficient to cover all use cases. So far it's mainly based on KDevelop, kcoreaddons, kservice & sonnet use-cases.
So far it was mainly: @broulik complained on irc, a day later I accidentally found another approach to the target-based hack we had in kdevelop, changed kdevelop cmake code, then pulled out the core logic and turned into this patch, after trying to port kcoreaddons, kservice & sonnet :)
Thus also hesitating to merge on first positive review, as I am not sure myself yet, still thinking of this as prototype to get feedback on.

I don't see other case. For me your macro works for all case that we can implement.

No other idea.
But avoiding to create by hand the file is a good idea. I never successed to create a macro for it
So thanks

Good. So will land this next Tuesday, Feb 11th then, so other people will have had 7 days of feedback opportunity.

@mlaurent Wasn't there also something which tells kdebugsettings about renamed categories? Is that documented anywhere? Could that be supported by some additional macro or adaption of the existing/new ones?

Yep you need to create a file name "foo.renamecategories" where you change the categorie name

old module name<space>new module name

for example "log_mailfilteragent org.kde.pim.mailfilteragent" in kmail

What do you need as " Could that be supported by some additional macro or adaption of the existing/new ones?" ?

In D27150#608318, @mlaurent wrote:

Yep you need to create a file name "foo.renamecategories" where you change the categorie name

1. old module name<space>new module name
   
   for example "log_mailfilteragent org.kde.pim.mailfilteragent" in kmail

Does kdebugsettings also support multiple renames? Like log1 > log2 > log3?

What do you need as " Could that be supported by some additional macro or adaption of the existing/new ones?" ?

We could have another argument for ecm_qt_declare_logging_category& ecm_qt_export_logging_category to pass old log names, and then have ecm_qt_install_logging_categories also generate & install a .renamecategories file. Should be easy to add, working on it next.

In D27150#608491, @kossebau wrote:

In D27150#608318, @mlaurent wrote:

Yep you need to create a file name "foo.renamecategories" where you change the categorie name

1. old module name<space>new module name
   
   for example "log_mailfilteragent org.kde.pim.mailfilteragent" in kmail

Does kdebugsettings also support multiple renames? Like log1 > log2 > log3?

Perhaps :) I will test it next week

What do you need as " Could that be supported by some additional macro or adaption of the existing/new ones?" ?

We could have another argument for ecm_qt_declare_logging_category& ecm_qt_export_logging_category to pass old log names, and then have ecm_qt_install_logging_categories also generate & install a .renamecategories file. Should be easy to add, working on it next.

oki

In D27150#608492, @mlaurent wrote:

In D27150#608491, @kossebau wrote:

In D27150#608318, @mlaurent wrote:

Yep you need to create a file name "foo.renamecategories" where you change the categorie name

1. old module name<space>new module name
   
   for example "log_mailfilteragent org.kde.pim.mailfilteragent" in kmail

Does kdebugsettings also support multiple renames? Like log1 > log2 > log3?

Perhaps :) I will test it next week

Would be good if it does, as I just found two candidates :) kcontacts & kcalendarcore now that they have moved to KF ideally would get rid of the "pim" subelement (and kcalcore renamed to kcalendarcore)

Preparing the new macros to support that now (already had first working draft only supporting one rename).

@kossebau - you have pushed commits depending on this change to several repositories, sometimes without waiting for acceptance, sometimes even bypassing Phabricator review completely.

You have ommited to update the minimum ECM version in all cases AFAICS.

Edit 2: About the direct commits: this has been done because the principal ECMQtDeclareLoggingCategory change and its application to some reference KF repos had been reviewed and accepted. Applying the same change to all the other repos was mainly shifting data around, without security class risks. Given the amount of people who are capable to add value by reviews for all those other patches is very small in this case, me being a developer who thinks he is experienced with CMake, has a long tradition in working on ECM & KF, takes care and responsibility for his commits, the actual changes being rather small and their effect easily testable by me before pushing (comparing old manual & new generated files for having equivalent content, build still passing) it is more economical for everyone to have me just go and apply the respective changes to all other KF repos, to ensure they are all consistent and the matter can be checked off in short time.
Previous mass changes done in similar fashion also worked out noiselessly, at least to what was brought to my ears :) so it seems the exceptions done here have been acted out with all the needed responsibility,

In D27150#619735, @bruns wrote:

You have ommited to update the minimum ECM version in all cases AFAICS.

Because that bump is done by the release scripts, and I did not want to mess with them.

In general it is expected that all of ECM & KF master depends on latest master of their peers. The dep version is only bumped in time for release preparation.

Edit: At least from what I have seen until now, other API additions to ECM & KF modules and their immediate usages in other KF modules also have not been done with a matching bump. Instead everyone seems to assume people make sure to update the other ECM & KF dependencies as needed when they run into such an issue.