>-----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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
