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

[René J.V. Bertin]

On Thursday September 24 2015 22:56:37 David Faure wrote:

> Maybe this needs to be per-method-call then.... :
> * if libA installs stuff into XDG paths, then it would find it using QSP::locate(type, filename, XDG)
> * the alternative would be QSP::locate(type, filename, Native), which would be the default.
> This seems more correct to me after all, no? Porting the KDE code would be just running
> one perl script, don't worry about that part.

I've whipped up an alternative patch that is a more or less rough implementation of this idea combined with my thoughts about it described earlier : cf.
https://github.com/RJVB/macstrop/blob/master/aqua/qt5-kde-devel/files/patch-QSP-multiple-conventions.diff

There's a problem with that approach, though: Qt itself uses QSP; at least QLoggingRegistry::init() (qloggingregistry.cpp:279 for Qt 5.5.0) uses QSP::standardLocations(GenericConfigLocation) to determine where to store/obtain the logging defaults (QtProject/qtlogging.ini) .

Using a per-method-call parameter with a default set when Qt is built means libraries calling QSP cannot be toggled after they've been built. For the particular file I happened upon this may be harmless, but I must admit I don't really like the idea. It's bound to lead to conflicts at some point (with full application of Murphy's law, evidently).

Of course we could combine the 2 principles to come up with a default convention that means "return the last used convention", but that would mean applications could end up using different conventions during a single run. So that's not an option either.

The more I think about it, the more I like the idea of a dedicated standalone framework that sets a (build-time defined) default convention, but can also be used to toggle the convention. That doesn't even have to go against what I said earlier about not targeting only KF5 applications, what with KF5 frameworks intended to be of general use :)
I reckon there is already a mechanism in place (in Qt or in KF5) to determine at runtime whether a class method is available (or some kind of weak linking), so that the framework will work with patched and unpatched Qt versions?

R.