David Fetter wrote:
As I am currently thinking about what I want to do in the next dev
cycle, this might be an opportune time for me to raise again my
previous suggestion of a distributed build farm, so we get timely
and automated warnings of breakage. I started creating a script to
do this, but got sidetracked onto more important things (like
Windows stuff, CSV, dollar quoting), but I am prepared to restart
the effort if enough people are interested. Essentially, this would
involve installation of a perl script to be run from cron (or
Windows equivalent - automating the build for Windows might be
challenging ...), which would check out code from CVS, run
"configure; make check" and then send the results to a central URL.
Centrally, we would store the results and have a summary page, with
access to full logs if necessary in case of errors.
How we classify the results is also an open question. So far my thoughts are to classify by <Architecture,OS+Version,Compiler+Version>.
Thoughts?
That'd be great! I seem to recall that bison/(f)lex versions can cause issues, too. Could these just be tested for beforehand? reported in any compile report? Should names & versions of other tools or libraries come along? If so, how?
Should not be necessary, at least for bison/flex - configure already checks that you have acceptable versions of these. If there is a failure due to them it should show up clearly in the logs.
Perhaps version info for other 3rd party things, like perl, python, tcl, kerberos, openssl would be useful. I'm wary of collecting too much info, though. Most compile failures seem to be traceable to OS/Arch/Compiler issues.
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
