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