[Development] [Interest] guidelines for modifying Qt's own build system?
steveire at gmail.com
Mon Mar 16 21:01:49 CET 2015
Thiago Macieira wrote:
> On Saturday 14 March 2015 18:34:08 Kevin Kofler wrote:
>> Thiago Macieira wrote:
>> > [moving to dev; interest in BCC]
>> > On Saturday 14 March 2015 16:44:33 René J.V. Bertin wrote:
>> >> 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?
>> If I understood correctly, his idea is that from the point of view of Qt,
>> the flag would be a RUNTIME flag. It would be passed by some inline code
>> in the application that depends only on the compile-time flags for the
>> APPLICATION, not for the Qt library. So different applications can use
>> different settings with the SAME Qt binaries.
> So you want to create a static library whose only .o has a global
> constructor function that sets this flag?
> That won't work. You'll need to pass -Wl,--whole-archive before that
> library and then reset the status so that the linker will pick it up.
FYI, CMake 3.1 has a feature to solve this kind of problem in the same way
qmake does for platform plugins in static builds (The CMake 3.2
documentation was improved but it is also true for 3.1):
I don't know enough about the issue in this thread to know whether that's a
useful feature in this discusion.
More information about the Development