[Development] [Interest] guidelines for modifying Qt's own build system?

[Thiago Macieira]

[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