Sorry, this should have gone to the list at once. Oswald Buddenhagen wrote:
Thanks, If anything this led me to the "Adding new configuration features" chapter in the QMake documentation. :) > qtcore_be_insane: DEFINES += QTCORE_BE_INSANE > SOURCES += $$PWD/data/qtcore_insanity.cpp > > src/corelib/corelib.pro: > > ... > MODULE_CONFIG += qtcore_insanity Will your qtcore_insanity lead just to an extra .a or .o on the linker command line, is that recipe going to build a different (additional) QtCore library/framework? I'm not sure if it was clear from my OP; the behaviour change I have in mind would be optional and absent if the module is not included. That's what made me lean towards modifying QT rather than MODULE_CONFIG > > all other build systems would have to be adjusted to grok that as well. What other build systems? Grok as in accept qtcore_insanity as an alternative for qtcore "tout court" or provide the equivalent? The former is clearly not what I'm looking for. > i suppose you could use weak symbols to make linking that object > optional, at least. not sure that can be done cross-platform, though. So it looks I wasn't clear. The behaviour switch I'm considering is specific to a single platform (OS X) and supposed to be achieved via a static method of the modified class. I don't want to modify all dependent code to call that method, so I'm using a dedicated class that calls this method in its ctor. The additional link module would just create a global static instance of that class. This should work as long as no one calls the modified class before that instance (or the 1st of those instances) is created (which I don't think is the case). And it means there's no need for weak linking; without the object, you simply get the default behaviour. I've already tested that principle with manual linking. It just works, maybe it's a crude solution, but it does seem to be an effective one. I really don't see what's insane about it except for the fact that it (shock, horror! :)) aims to modify factory behaviour. But do enlighten me! :) Alternatively, I suppose the behaviour switch could be triggered by the sheer presence of specific function provided by the additional module, that should remove the possible race condition, and probably also the risk that the static instance is somehow "optimised away" by a too clever linker. > we (mostly thiago and me) discussed exactly this thing quite a while ago > on gerrit (or jira?) with somebody - wasn't that you? Quite likely, but it never gave me anything I could actually go to work with... Didn't think it was *that* long, but then again that's quite likely too, knowing me. R. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
