[KDE/Mac] QSP - we're getting somewhere?

René J.V. Bertin rjvbertin at gmail.com
Sat Mar 14 01:18:03 PDT 2015


On Saturday March 14 2015 13:00:51 Ian Wadham wrote:

Hi,

>Well, I think we really are (getting somewhere).  Keep pushing! :-)

>I have read through the patch in detail and it looks great.  A couple of points:
>
>    a. Is it necessary to initialise QStandardPaths::usingXDGLocations in every
>        platform file (android, blackberry, etc.)?  Could it be done in conditional
>        code in qstandardpaths.cpp?

No, and yes but no :) I've already changed the patch with a bunch of #ifdefs such that it injects my code only on OS X. I think it's better to initialise the state variable in the platform-specific implementation (if not only for readability) so it's remained in qsp_mac.mm (and only in that file).

>    b. How does the qstandardpaths_use_xdg.cpp component work?  I guess
>        it is intended to be loaded with any build that wants to use Qt with XDG
>        paths (e.g. all KF5 Frameworks and apps), but what actually makes it
>        execute and when?

Yes. That part still needs work. Ideally that file would be built along with the rest on Qt on OS X, to yield a link-time object.
The various buildsystems that expose QtCore to applications could then provide a way to link that object through a flag, or it could be left to the KF5 build system.
The object itself could be a static lib (requiring -force_load because it doesn't contain anything that's referenced) or possibly a shared lib (which could use the shared-lib initialisation feature to ensure it actually does something?). But it it's sufficiently transparent there may not even be a point in trying to hide a lowly .o file from the user :)
And in that latter case it could be built from Qt's configure script, which will be way easier to do than to hack its qmake build system. Because the one inside Qt seems to work not exactly the same way as it does "outside" of Qt.

>So perhaps it does make sense to re-use ${prefix}/etc/xdg in Qt5/KF5.

I have nothing against that...

R.


More information about the macports-dev mailing list