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

[Mcgovern Rohan (Nokia-MP-Qt/Brisbane)]

Blasche Alex (Nokia-MP-Qt/Brisbane) said:
> I don't understand why this definition matters. How does the exact code path matter?

Well, it mightn't matter to the user of the API (assuming all code paths
work equally correctly).  It matters when attempting to test them, which
is what we were talking about.

> 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?
> 

I went through and did a brief review of the config tests and how they
are used.  Actually, the situation is not as bad as I thought, so I
mostly retract my "overuse" accusation.

It does still seem possible to accidentally build a no-op version of
libQtBluetooth (on Linux and no bluez - which at least warns) and
libQtPublishSubscribe (on Linux and no contextkit, gconf or jsondb).
Are these really of any value?
If someone filed bugs for these configurations, any chance they would
actually be fixed, or would they be rejected as "please install <some
prerequisite package> and try again"?