WIP: Add ECMQLoggingCategoryHelpers

WORKING PROTOTYPE DRAFT, WANTING FEEDBACK

A successor for ECMQtDeclareLoggingCategory with more emphasis on separate definition of data around a logging category and generating files out of that (C++ code, kdebugsettings data, ...). Tries to support these cases with least minimal client-side code needed:

• simple project with just one category
• simple project with multiple categories
• complex project with subprojects, with separate groups of categories as well as reused/shared ones categories

Also a first step in the direction to solve https://phabricator.kde.org/T12741 ("Central location to define and document all Qt logging categories in a repo"), by having the declaration of data separate. Next step would be writing code to parse in the data from a separate file instead of having the data only in cmake code. Writing such parsing code is little fun to do in CMake syntax, though, so nothing to await soonish by someone. In the mean time, ecm_generate_qloggingcategories_mddoc() instead can be used to maintain a MD file in the sources which then is picked up by the API dox generation.

Sample for a simple project with just one category: kwidgetsaddons!58 (closed)

Sample for a complex project with many categories reused across subtargets: kcoreaddons!80 (closed) That presents a typical problem: autotests reuse source files from the source folder which use logging categories. As the QLoggingCategory object needs to be part of a source file, not a header, when using generated code we either have to help the autotests also finding & picking up any generated files in the build dir matching the source dir, or regenerate/mock the expected additional files in the autotest build dir. I personally favour the latter, as it means more control over the test setup (and avoiding clutter from other artifacts in the normal source build dir). For proper regeneration the cmake code defining the logging categories data needs to be called before the autotest & src folder cmake code, following the cmake execution flow, otherwise the data is not known there (no known way to delay data lookup here, any ideas?). Which would be the main CMakeLists.txt file. To not clutter that file, the proposal is to have a separate cmake file with just the logging categories data setup, with a typical file name pattern to help discoverability, perhaps "QLoggingCategories.cmake". Having such a file with dedicated code & data in the toplevel folder also would serve to a good degree the need to look up existing categories quickly.

A more complex project with many categories reused across subtargets: kio!353 (closed) There was a mix of subdirs with and without project() calls (and thus controlling the group default names) which made things a bit confusing perhaps, as sometimes the GROUP argument is used and sometimes not, so people just copying magic cmake lines might miss out things. Not sure yet how to approach that. This example (now) does also make use of a central "QLoggingCategories.cmake". The challenge of source files being reused in autotests is still solved by having non-generated code for logging categories in those files. If we define the goal to have all such code generated, to avoid data duplication while having processable data about used logging categories, this then should be ported to the approach used with kcoreaddons.