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

[René J.V. Bertin]

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.

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).

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.

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?

Thanks in advance,
R.