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é
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
