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,

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

They used to work back when I added the code for it. Maybe it broke over time. If it works for you, go for it.

In D27596#616554, @apol wrote:

Don't we need an if Qt 5.13 elseif Qt 5.14?

In other Qt versions it won't be in the assets...

I guess nobody has further input then.
LGTM. Ship it.

Don't we need an if Qt 5.13 elseif Qt 5.14?

Patch makes sense to me overall, we could consider landing it.

The WARNING tags should be removed or changed to AUTHOR_WARNING I think. A stray call to one of the functions here isn't really something a user building a tarball, for example, can do anything about, so WARNING seems wrong.

Add support for also generating renamecategories files

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

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?

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

I reviewed the current state and there is now already icotool support in our extra-cmake-modules stuff => closing this.

In D24568#563653, @cullmann wrote:

For the lambda issue, I think we can add:

# keep lambda formatting multi-line if not empty
AllowShortLambdasOnASingleLine: Empty

see https://clang.llvm.org/docs/ClangFormatStyleOptions.html

That fixes for me the issue with the collapsed lambda.

For the comments, as said, we can remove

AlignTrailingComments: true

For the generic issue of stuff folded in one line, one can play with the ColumnLimit, but as said, that will still arbitrarily pack stuff as long as it fits the limit.

Kai, could you try the two changes (for lambda and comments) by just temporarily changing that in the .clang-format file locally and rerunning make clang-format?

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

1. old module name<space>new module name

@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?

Pushed a8c3ab79912fcb25d7e59a04c08752a9252a5f08 as hotfix for now.

This breaks stuff in PIM:

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

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

@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.

Seems ok for me :)

in doc also be explicit that ecm_qt_install_logging_categories can be in
another directory, just needs to be called last

Excellent news! Could you post your Kirigami patch somewhere maybe? Makes this easier to test here :)

I want to remind about topic.

I got my Kirigami app to load by patching kirigami.{cpp,h}:

Seems ok for me

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.

Thanks for this.

• Fix Variable

I don't really understand why this is needed, I've never needed that at least.

I'm now affected by this :(

@apol I did update the commit body to explain why.
For the text I used https://regex101.com with the icon in the commit body and printing the variables of CMAKE_MATCH_1 and CMAKE_MATCH_2
Let me know if you agree with this to land the patch, this is necessary to continue D26752

Add commit body

Hi @cgiboudeaux, thanks for the explanation, I'll take a look and get back here.

In D26752#597149, @patrickelectric wrote:

Hi @cgiboudeaux and @bcooksley, there is a reason of why this patch is valid. Have you read the commit message ?

In Kirogi we provide a valid icon (svg) with a valid prefix (sc), as you probably know *sc* stands for for scalable (SVG) files.

Looks good to me, bonus points if you provide a better commit message explaining what it does and how you tested it.

Hi @cgiboudeaux and @bcooksley, there is a reason of why this patch is valid. Have you read the commit message ?

Christophe is correct here, it is worth warning developers about these issues regardless of the platform, so they can get the code ready for those platforms and test everything in their local environment as much as possible.
I know for certain that there are developers who rely on our CI system and the Binary Factory to test and validate their applications (because they themselves do not have access to a development environment on those platforms).

In D26752#596949, @tcanabrava wrote:

I think we are misunderstanding eachother here.
If I'm developing the software and running cmake all the time, having a
warning that I can't fix (because it depends in another platform) is noise,
but still being a developer I don't want to run with -Wno-dev.
I do work in applications that targets more than one system (and they are
mac / windows / ios / android) I tend to use buildhosts, and those
buildhosts will tell me the warning - if any. But only if I'm targeting
them.

In D26752#596809, @tcanabrava wrote:

That’s not a developer issue, it’s a packaging issue.

That’s not a developer issue, it’s a packaging issue.

You may use Linux to develop software that's intended to be used also on Mac and Windows. You can't expect developers to have build environment for every platform

But why would I get the warning if I build on Linux? The warning should
target the platform, not the entire build system.

I object. This warning is for developers. It tells them the icons are missing for some platforms.

From ECMInstallIcons:

Ping? Any update if somebody tried the proposed changes?

Corrected logic, so it is is in line with GNUInstallDirs. Explained in comment. Added tests.

@heikobecker are you still interested in this patch? I can take over otherwise.

(Just remember that using KDE_INSTALL_KNSRCDIR though needs at least KNewStuffCore from KF 5.57 (hint was missing in API dox, proposing D26248 to fix that).)

Not saying that this patch is wrong, would have to look into it more closely.

In D24568#580338, @kossebau wrote:

This has been missing the link from an rst file in docs/, so the documentation generation picks up the file. Fixed with c4890d5c03ed79f0c87da861b6608bbd46c2162c

This has been missing the link from an rst file in docs/, so the documentation generation picks up the file. Fixed with c4890d5c03ed79f0c87da861b6608bbd46c2162c

Use HINTS

LGTM overall