[LinuxBIOS] r2477 build service

Stefan Reinauer stepan at coresystems.de
Fri Oct 27 21:28:46 CEST 2006

* Richard Smith <smithbone at gmail.com> [061027 19:49]:
> >> list?  That could be the first step for getting it approved.
> >> That way you know its abuild clean before you review it.
> >
> >Are you suggesting a development and a stable tree?
> No.
> >Is this better than running abuild locally? (besides potential tool
> >chain issues)
> Because on my laptop (which I do a lot of work on) it takes over an
> hour to run abuild.  I suspect a lot of people don't run abuild localy
> since it takes so long to run.
opening this up for any number of build runs for any number of users 
will render a single machine pretty slow, too. 

> But you have abuild on a fast machine that I can send my patch to and
> in 5 minutes or so I get an aswer then (the developer) seems more apt
> to try and check it before you check in breakage.

the 2*1800MHz Opteron does it in 35 minutes, if its the only job
running. And that's only if you don't rebuild the documentation.
Imagine you and Yinghai and Ron working at the same time. This will
render the compile time slower than what your laptop is capable of doing
at the moment.

> Also the reviewer could send the patch at the start of the review
> process and by the time he is done reviewing have an answer if its
> abuild clean or not.
This could be done with a pass-through repository as well. You check
into a devel tree. the devel tree is running an abuild. If it succeeds,
it goes to the stable tree, where hw tests are run. if it works there,
it continues to a "working" tree.

the reason I am talking about trees all the time is that exactly the
move stuff we've been doing recently requires a patch format that
reflects those changes. A check in to a tree is such a diff. We could
also do a branch for each compile run.

> Part of the patch submission requirement would then be to have it
> abuild tested.  If the script succeeds then it could issue a
> Abuild-clean: <date> or something like that which the submitter would
> include in the patch.

one thing, which would also allow a really quick checking on your own
machine (or therefore centrally on linuxbios.org as well) is to drop 
romcc. This will get build times per board from several minutes back to
several seconds.

Which in fact would maybe even allow to compile the tree on checkin and
reject the checkin if something breaks.

This could even be done intelligently. If you check something in to
the flashrom utility, no board needs to be rebuilt. If you check
something in to the k8 part, epias dont have to be rebuilt either.
and we're at about 2 minutes per complete compile run.

> Then at least you know its passed abuild before you commit.

coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.dehttp://www.coresystems.de/

More information about the coreboot mailing list