[Development] adding a custom entry to qmake's QT (or CONFIG?) commands

[René J. V. Bertin]

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.