On Wed, 2009-02-18 at 12:00 +0100, Stephan Bergmann wrote: > I assume that many buildbots use additional configure switches that > influence the functionality of the resulting OOo. ... (I do not know > where to easily look up which buildbot uses which switches, so I did > not bother to check.)
Navigating around to see a successful build on a random linux build-bot it should be visible at the top of the configure log section, e.g. looking at a sample line http://buildbot.go-oo.org/buildbot/builders/Ubuntu-7.10-i386/builds/658/steps/Configure/logs/stdio I see just configureswitches='--enable-werror with_jdk_home=/usr/local/jdk1.5.0_12 --with-package-format=deb' for that one. Which would suggest that it is using Sun Java 1.5.0 and no other relevant configure options. So that would be an ideal starting point to example a sample build that comes out of that build-bot with a vanilla one. The default configure options are supposed to mirror the default Hamburg setsolar env as close as is practical (e.g. werror is off by default in configure vs setsolar as there are too many compilers with different warnings in the wider field, and the default it to build the mozilla stuff from the old mozilla source tarball rather than prompt to download the pre-built stuff as there isn't pre-builds available for all archs etc, and on systems where prelink has made libgcc_s.so.1 unusable its automatically dropped from the installs at configure time with a warning) > A third factor might be that different build machines have different > versions of compilers and linkers installed, I would assume that this > has much less influence on the observed variance than the configure > switches, however. I suspect it has quite a degree of influence unfortunately. There has been a quite incredible sequence of weird-ass gccs floating around in the 4.0 to 4.1 range. I don't actually think that its a matter that the build bots configure switches are destroying an otherwise flawless set of builds that would be functionally identical to the Hamburg vanilla set. > So, in an ideal world, for all the important platforms for which we > provide standard builds we should also provide buildbots that produce > builds that are (close to) identical functionality-wise to the standard > ones. I would love to see someone pick up on this, presumably from the > zSun Hamburg infrastructure group. My understanding was that the o3 developer cd was an attempt to provide the same compiler and baseline etc. as used in Hamburg for externals to build OOo against. I never had much success with using it directly, *but* I was able to use that o3 compiler with an old Fedora Core 3 chroot which I've used successfully to generate install sets which pass Hamburg qa without getting caught on irrelevant problems caused by various compiler, binutils, prelink, too-new gtk version, etc problems which absolutely plague efforts to create workspaces which both work on Hamburg test machines with equal results to the baseline build. C. (Of course its not the case that the baseline compiler is some magic compiler free of errors, just that its errors are typically known and the optimization workarounds for the Hamburg compiler get hacked in for that version) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
