On 1/23/06, Laurent GUERBY <[EMAIL PROTECTED]> wrote: > Hi, > > I've put in place a script that monitor svn log on trunk and launches > a bootstrap + check on each commit (distributed on the 7 CFARM ubuntu > machines). On average since Nov2005 there have been 20 commits per day > on trunk so, a cycle taking about 8 hours I expect to use about 50% > of CFARM ressources for this task. I'm currently limiting to one build > per machine to leave a processor for other users of CFARM. > > I still validate manually the output before sending to gcc-testresults > but that will change soon (when I'm confident that it survives a few > problems), see current results with subject "[r1100xx]": > http://gcc.gnu.org/ml/gcc-testresults/2006-01/ > > I'm currently using the following configure flags: > --disable-nls --disable-multilib --enable-languages=c,ada
What you could try doing is restricting the enabled languages if a patch touches only frontend parts (i.e. a subdirectory out of cp/, fortran/ ada/, etc. in gcc). In this case only enable c and the affected language. Likewise if only a toplevel target library like libstdc++ or libjava is affected. > So build & check takes between 4h30 and 6h00 depending on the > processor frequency. Adding other languages will push that figure to > 6 to 8 hours (last time I checked). CFARM is a bit behind on commits > since I launched my script starting with r110006, it has currently > done up to r110047 and has 25 revisions to go (as of r110115). > > Is sending each rev testresults to gcc-testresults ok? Yes, I think that is useful. > I have a serie of build which failed (gcov build ICE), r110009 to > r110025, what to do with those, email to testresults with end of build > log? > > Next tasks will be: > > - Activate more languages. What languages, what configure flags are > useful? See above. In general, enabling all default languages is useful, though enabling java/libjava will push the requirements way up. > - Activate build & check on branches. I think this is less important, as other daily(!) testers build the branches, too, and with the commit frequency on the branches this already should capture nearly every revision. Richard.
