[Development] Optional Qt module dependencies (was: RE: qtsystems doesn't compile...)

[alex.blasche at nokia.com]

>-----Original Message-----
>From: Mcgovern Rohan (Nokia-MP-Qt/Brisbane)
>Sent: Wednesday, 2 November 2011 11:10
>To: Blasche Alex (Nokia-MP-Qt/Brisbane)
>Cc: development
>Subject: Re: Optional Qt module dependencies (was: RE: [Development]
>qtsystems doesn't compile...)
>
>Blasche Alex (Nokia-MP-Qt/Brisbane) said:
>> >-----Original Message-----
>> >From: development-bounces+alex.blasche=nokia.com at qt-project.org
>> >[mailto:development-bounces+alex.blasche=nokia.com at qt-project.org]
>On
>> >Behalf Of ext Rohan McGovern
>>
>> >Incidentally it's rather dangerous to do this kind of
>> >
>> >  contains(QT_CONFIG,some_module):QT+=some_module
>> >
>> >...behavior nowadays.  In Qt4, QT_CONFIG would be decided at configure
>> >time, but in Qt5 it can be changed when you qmake additional modules.
>> >
>> >In other words, if you test contains(QT_CONFIG,some_module) in your
>Qt5
>> >module, you've made your build behavior implicitly depend on the order in
>> >which the user happened to run `qmake' over the qt5 modules, which is
>> >largely undefined.  e.g. if you are doing a `make -j20' in qt5.git, the
>> >qmakes are also parallelized, and your result might flipflop between
>> >builds.
>>
>> Surely there must be a way of enforcing dependencies between Qt
>modules. How would somebody create such a dependency? Is it a matter of
>mentioning it in sync.profile? Note that the dependency might be platform
>specific on and currently I don't see a way of specifying it in syn.profile.
>
>Just do
>
>  platform_specific_scope:QT+=some_module
>
>That will give you a big warning if some_module is not available.
>
>IMHO it should be changed into an error, in the meantime that could be
>simulated by
>
>
>platform_specific_scope:!contains(QT_CONFIG,some_module):error(some_
>module is required!)
>  QT+=some_module

Thanks.

>Incidentally I think config tests are overused in various qt5 modules at
>the moment - qtsystems for example has 6 config tests, all of them
>non-mandatory, doesn't that give 2**6 => 64 possible build
>configurations?  Surely it's not intended to actually support them all.

That's a bit of a trivialisation of the mater. The 95 config tests in qtbase would otherwise be worse ;)

Your statement holds only true if every combination would influence each other. qtsystems has three libraries.
Gconf and contextkit are mutually exclusive and only apply to P&S.  Bluez and udev apply to system information only and wayland for SFW only. Jsondb is the only one applying to all. 

Also your 64 combinations assume that enabling Bluez related code paths would change for example gconf/contextkit code paths. In most cases enabling one doesn't change anything for the other (jsondb is just about the only exception).

Last but not least qtsystems accumulates information from a large variety of system components. It is only natural that it has to do a few more tests than normal.

--
Alex