[OS X] adding a link module to all KF5 targets

[René J.V. Bertin]

Hello,

I'm working on a Mac OS X specific patch that would require adding a small object (probably a .o file) to the link list for *all* targets that use KF5. This object contains some logic that flips the behaviour of a central Qt class which is likely to be used by (almost) all code that depends on (or is part of) KF5 : QStandardPaths.

The question : what is the best way to achieve this? Presuming that KF5 uses CMake exclusively for its build system, is there a place (macro, default list, whatever) where such an object can be added in some kind of conditional way (the ECM, for instance)? Or how else would I best proceed?

The context (longish):
On Mac OS X, QStandardPaths (QSP) returns locations that conform to Apple-imposed guidelines that are compatible with App Store sandboxing and admission rules. In a nutshell (undoubtedly oversimplified), there are little to no shared locations with a direct common parent directory and applications are not supposed to be able to access configuration files or data also used by other applications. We have attempted to introduce changes to Qt, with help from David Faure, but this has been rejected due to lack of cohesion and knowing what we really need on our part. In a subsequent bug we did obtain recognition of specific needs though:

Distribution systems like MacPorts (a main "source" of KDE4 installs on OS X) provide the equivalent of Linux's shared system Qt. They do however not only provide FOSS software from Freedesktop contexts, but also provide ports/packages/recipes/... for pure Qt open source software. The latter must be able to build and function with the distribution's Qt as it would with a generic Qt install, and thus get QSP locations that follow Apple's guidelines. The former however should be able to get QSP locations that follow Freedesktop/XDG guidelines. This should at least help us make KF5 function (which it doesn't, currently) but should also allow interaction with non-KDE Freedesktop ports (GTk/Gnome apps; think something as basic as sharing icon themes).

With KDE4 it was easy to implement OS X specific adaptations in KDELibs, which made to changes visible to all (well-behaved) KDE applications, and not to pure Qt apps. With the migration of so much KDE functionality to Qt this is no longer an option.

For QSP, I have thus implemented and tested a patch that allows to switch behaviour from returning the (default) Apple-style locations to returning XDG-ish locations (${prefix}/share, ${prefix}/etc/xdg, etc.). To increase chances of future acceptance into Qt this switch can only be toggled once, and in my intended implementation this is done in the ctor of a specific class of which a global, static instance is created in the aforementioned link-time object.

This has a number of advantages:
1) the switch is effective before main() is called (thx Ian Wadham for suggesting this)
2) no existing KF5 code has to be changed (=> better readability, less maintenance issues)
3) (to be confirmed:) adding the object can be constrained to the KF5 build system without modification of the qmake or cmake build systems of pure Qt applications. This should make the change more acceptable for inclusion into Qt.
4) the addition of the link-time module could be made optional once it is clear that KF5 can also be made to function with Apple-style QSP locations. (I strongly feel that question should be addressed only when KF5 functions satisfactorily with "normal" QSP locations.

The question is of course whether there is a chunk of CMake code (CMake file) that is executed or loaded by all projects that depend on KF5. I'm new to this aspect of development (taking it up because no one else seems to be motivated to do so) and have been contenting myself with KDE4 until now. From what I've seen, one possible candidate for such common CMake code 
could be the ECM, but are they used by a sufficiently large majority of KF5(based) projects?

Thanks for reading all this!
René