On Wed, 2006-03-01 at 20:57 +0100, Thorsten Behrens wrote: > Stephan Bergmann <[EMAIL PROTECTED]> writes: > > > However, some people build OOo in such a way that they use > > system-supplied alternatives of those external projects, so that the > > patches will have no effect for them. That means that switching on > > "warnings are errors" can break such builds (although the "official" > > OOo builds would succeed). The relevant patch files, until now, are > > boost/boost-1.30.2.patch > > boost/spirit-1.6.1.patch > > icu/icu-2.6.patch > > neon/neon.patch > > python/Python-2.3.4.patch > > sablot/Sablot-0.52.patch > > stlport/STLport-4.0.patch > > stlport/STLport-4.5-0119.patch > > > Add agg to the list.
I guess that for e.g. next version of Fedora, I can go around getting the warnings free patches for this libraries into at least the distro versions of these modules so at least a --with-system on fedora > fc5 would work with warnings as errors enabled, and I assume that other distros could do the same. The problem would be using --with-system-foo on existing releases :-( Have you already submitted the "fix warnings" patches for these libraries into their respective bug tracking systems, so that the next releases of those libraries themselves will include the warning fixes :-) ? > But what about providing tinderbox slaves, dedicated to community CWS? This would be a good idea, especially is organized so that someone who wishes to create an install set for qaing a workspace can generate a "Hamburg QA" compatible workspace for various platforms by submitting a job to build it and auto move it to somewhere where it can be downloaded. C. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
