Any chance this could not be done by abusing KDECMakeSettings.cmake as injection vector? I know you are just following the example of what was done for appstreamcli, but IMHO this has already been a bad hack, screwing over the fine granular design of all the ECM modules trying to keep aspects separate. And yes, by the price of the overhead with more explicit module includes, but it's like that. Or we should just screw it and put everything in one big "KDEECMEverythingEvenKitchenSink.cmake" ;) And yes, one possible would like to have such a generic wrapper module in any case, for quick prototyping. But the individual modules should stay focussed.

The Binary Factory uses the tooling shipped as part of the KDE SDK (which always builds everything from scratch, and I don't know if part of that includes ECM, hence why the issue doesn't show up there).

In D21313#480401, @kossebau wrote:

@apol @vkrause Perhaps something to check wit the CI or in general with the ECM Android toolchain to make sure the ECM of the host and the target are not accidentally mixed or both visible at the same time.

In D21313#480332, @bcooksley wrote:

This change appears to be responsible for all Android builds being broken.
See https://build.kde.org/view/Failing/

Could someone take a look please?

This change appears to be responsible for all Android builds being broken.
See https://build.kde.org/view/Failing/

• add options to take identifiers/type names from file base names
• add option to specify version suffix to install path

In D21695#476826, @heikobecker wrote:

I'm not entirely sure about taglib-config on Windows

Where does this FindTaglib.cmake come from?

attic/modules/FindTaglib.cmake shall be deleted.

Certainly a good idea to have this in ECM, so that this mess can be sorted out once and for all...

I'm not entirely sure about taglib-config on Windows and Android (can't test there), but similar to pkg-config I omitted the special casing. Tried to test this by moving taglib-config out of the way on Linux and a taglib install in default locations, which worked fine.

Fix typo

Maybe also update the commit message to 'Create specific directory for Qt logging categories file'

So ? :)

Change as qlogging-categories5

Thanks david.
Indeed qlogging-categories5 seems a good name :)

My suggestion is to call this qlogging-categories5.

In D21381#469617, @apol wrote:

How about we test against both?

• use appstream-util and appstreamcli to validate appdata file

LOGGINGCATEGORIESDIR indeed it's more specific +1 for me
debug-categories5 => indeed it's just using by kdebugsettings at the moment. => kdebugsettings-categories5 ?
no idea if it's better.

Aleix is correct, Flatpak commands are not possible within the CI environment (as Docker is heavily locked down, and the containerisation and other isolation measures that Flatpak tries to take are locked out as a consequence)
Not to mention that Flatpak is Linux only as well, while Appstream data isn't applicable to multiple platforms.

How about we test against both?

Oops indeed I forgot to readd KXMLGUI_INSTALL_DIR

In D21313#469311, @mlaurent wrote:

Ping ?

Ping ?

Renamed to ECMAddQmlModule, with more helper macros for non-C++ parts

Use DEBUGCATEGORIESDIR and debug-categories5

DEBUGCATEGORIESDIR is fine for me too

+1

Looks mostly fine safe for the directory name that needs the major version to avoid conflicts when libfoo.categories built using KF5 will have to coexist with KF6.
It needs a '5' in its name.

Remove unrelated change

Fix comment reported by Christophe Giboudeaux

Forgot to commit before creating diff

Add also support for TYPEINFO, merging main logic of ecm_generate_qmltypes

get rid of newer list(TRANSFORM)

Use file(WRITE/APPEND) over file(GENERATE), for less intermediate vars

In D20984#460128, @apol wrote:

wouldn't it be almost as complex to file(WRITE ... qmldir)? Most of the code is to construct the file.

wouldn't it be almost as complex to file(WRITE ... qmldir)? Most of the code is to construct the file.

Add DEPENDS & DESIGNERSUPPORTED, nothing complicated there (besides going
for asking string with pair of identifier & version, to avoid any arg clash
& make parsing easier)

Possibly the ECMGenerateQmlTypes could be also merged somehow, but I have no experience with that, so leaving to someone else to improve here.

well.. I couldn't get it running as a toolchain and kept running into errors.

In D20558#451898, @sh-zam wrote:

In my case if I do this: include (Android.cmake), then it won't be able to find the ECMAndroidDeployQt.cmake because I am using android-ndk's toolchain.

What does it mean that "it expects to run as a toolchain"?

In D20558#450229, @sh-zam wrote:

Why are you using it without Android.cmake?

I am building Krita and to add create-apk target I am using include (ECMAndroidDeployQt.cmake), I can't use Android.cmake because of some variables as it expects to run as a toolchain.

• disallow whitespaces in path

Why are you using it without Android.cmake?

• disallow whitespaces in path

In D20558#450198, @sh-zam wrote:

Can we add a cmake_minimum_required to 3.7? Regex fails to compile on older versions, when run outside of Android.cmake.

Looks good to me, can you land it?

Can we add a cmake_minimum_required to 3.7? Regex fails to compile on older versions, when run outside of Android.cmake.

improved name and code flow

minor typo fixed

All the modules that use this cmake file, already build fine in debug mode with strict iterators.
This enables the same setting in release mode, for code that already builds fine in debug mode. So unless people have bad code in #ifndef NDEBUG, I don't expect this to break anything at all.

Are we sure we don't break code by introducing this? Or we're just going to play Whac-A-Mole with compile errors until all it's compiling again?

Hmm it looks like we're using ancient code option.

FWIW, I have meanwhile used this patch to build all kube dependencies on linux and osx as well, and it seems like it doesn't break anything.

for generating server files too

LGTM, looks like clang-cl will be missing a few arguments though.

There was already an earlier (abandoned) attempt at this: https://git.reviewboard.kde.org/r/128779

fixing a typo.

make parallel network requests.