On 26/09/2011, at 11:28 PM, Thiago Macieira wrote: > On Monday, 26 de September de 2011 13:13:09 [email protected] wrote: >> Thiago wrote: >>> So I'd consolidate the list as: >>> Linux x86 32-bit, X11 & Wayland >>> Linux x86-64, X11 & Wayland >>> Linux ARMv7, X11 & Wayland >>> (maybe dropping X11 support for ARM) >> >> This list aims to be specific enough to describe what actually would run in >> the continuous integration system, hence it mentions Ubuntu. In the >> release documentation or product documentation, we should be more generic, >> "extrapolate", and include the other non-reference platforms that have been >> verified. > > I think that's doing it the other way around. The release documentation > should > list exactly where it was tested, but the reference platforms should be > generic enough. > > For example, if someone writes a feature that compiles on Ubuntu but fails to > compile on Fedora, it's still in need of fixing. Such errors would be usually > cases of depending on undefined or buggy behaviour in one of the libraries > installed or of the compiler, so they should thankfully be quite rare.
This discussion about what to make a reference platform vs documented platform seems to be specific to Linux (okay, maybe embedded too, but discussion seems to be mostly about linux at this stage). I put it to the list that this is precisely what the LSB is meant to address. Most of the work has already been done to make Qt build against LSB 4.0 (by Harald Fernengel and myself). Why not make LSB 4.0 the reference *and* documented platform for linux? Then the only question is whether or not a particular flavour of linux supports the LSB spec, and this is something that all the major linux distros generally try to do. Yes, there will be the odd need for a specific hack/fix to work around the occasional distribution-specific deficiency or bug, but I'm only aware of one such case in order to make Qt build against LSB 4.0. Qt5 would seem to be the perfect time to make LSB 4.0 a tier 1 config/platform for Qt. Currently, I maintain a smallish patch set for each Qt release to make it buildable with LSB (almost all the patches now are confined to webkit). I'd be more than happy to work with others if there was interest in making LSB 4.0 a tier 1 config/platform for Qt. Currently, I can only work on this as my current role allows, so some help would be welcome. Granted, there are some issues around OpenGL versions, but those are easily resolved by adding an additional constraint that sits on top of LSB 4.0 (and which looks to be getting addressed by upcoming LSB versions anyway). The only module I have not yet built against LSB 4.0 is DBus, since it isn't part of the LSB, but Thiago has already indicated in a previous response that providing the DBus headers to Qt should be enough since it will try to load the QtDBus module dynamically at run-time and still work fine if it can't be loaded. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
