[moving to dev; interest in BCC] On Saturday 14 March 2015 16:44:33 René J.V. Bertin wrote: > Hello, > > I am working on a patch for QStandardPaths and a switch (to toggle between > OS X "native" locations and XDG/Linuxy locations) that should be applied > when building a Qt application, or at the latest when such applications > start up. The main (or at least of the biggest) class of applications that > are to benefit from this patch are KF5 applications. That's a pretty large > lot, one of the reasons why I would prefer to make this switch operate > through the build system and not by a modification to myriads of source > files.
Understood, but wasn't there an argument that the same Qt could be used by applications made to understand the OS X intricacies, like VLC? > My current approach adds a state variable to QStandardPaths (QSP) set by > default to "use the native locations", and a protected setter that can be > called from the ctor of a friend class (QStandardPathsConfiguration) > defined in a new headerfile (qstandardpaths_p.h). When that class is > instantiated in a global variable in an additional link object, the QSP > functions return XDG/Linuxy locations for certain relevant location types > (data, config and cache). Why do you need a class for this at all? Seems like a simple setter is enough. > The question is now how to integrate this into a build system. It's not up > to Qt to know who is to add this additional object, but adding an object > module or (static) library when a build flag is set isn't very hard nor > invasive. I don't understand the question. You added a class to Qt, so it has a .cpp and a .h. Add them to src/corelib/io/io.pri. Whoever uses the class is irrelevant. Are you asking how to conditionally include a source file? That requires the configure script setting something in QT_CONFIG, which you can then check in src/corelib/io/io.pri. > Creating the additional link object is a different matter. I think it stands > to reason to do that while QtCore is built. I've started to write a .pro > file that builds a static library containing just that one file. It almost > works, except that for some reason qmake doesn't add the Qt header > directory to the search path. As a result, I cannot use header includes > like <QtCore/QtGlobal>. I haven't seen any specific code that handles this > in corelib.pro nor the .pri files it includes, so how is this done? An > additional question: how and where do I add my .pro file to the system? I'm questioning your solution to the problem. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
