[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 13:05
>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:
>> >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 ;)
>>
>
>I never said I liked the situation in qtbase :)
>
>> 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).
>>
>
>So you're asserting that only certain combinations are relevant, which
>is great :)  What's not so great is that they aren't defined.  For
>example, we advertise "Ubuntu 10.04 x86 32-bit" as a supported platform,
>not "Ubuntu 10.04 x86 32-bit with gconf, contextkit, bluez, udev and
>wayland".  Does anybody even know which code paths are enabled in the
>CI without going to check the logs?

I don't understand why this definition matters. How does the exact code path matter? One might argue that the provided feature is the same. For example in a cross platform fashion you can figure out whether Bluetooth is enabled on your system. In a sense we already figure this out as part of the compile tests....

If we take a more complex example such as gconf and contextkit, why do we need to advertise that it is gconf or contextkit underneath? From an API perspective we promise that the P&S API feature set is available. To take a similar analogy I don't have to care whether my hard drive is a solid state disk or a conventional magnetic drive. My file system abstracts it away. 

What it does make more difficult is testing in the CI. Unfortunately (some might say fortunately) Linux/Unix is not as homogenous as Windows (but even here you have different Bluetooth stacks depending on your Windows).

All this aside, what would you like to see happening?

--
Alex