[Buildroot] howto incorporate buildroot into an autobuild

[Buildroot] howto incorporate buildroot into an autobuild

[John Stile]

I am using buildroot for an embedded Arm project.

I was wondering how people using buildroot implement continuous
integration builds?

Do you start from a clean checkout, build the whole tool chain (which
takes a long time), and then build the project specific stuff?

I worry about not starting from a clean checkout, since some options may
change, and the tools won't be rebuilt.

But I also worry people will complain how long the build takes.

Is there a good strategy to balance these concerns?

[Buildroot] howto incorporate buildroot into an autobuild

[Avery Pennarun]

On Mon, Nov 12, 2012 at 7:47 PM, John Stile <john@stilen.com> wrote:
> I am using buildroot for an embedded Arm project.
>
> I was wondering how people using buildroot implement continuous
> integration builds?
>
> Do you start from a clean checkout, build the whole tool chain (which
> takes a long time), and then build the project specific stuff?
>
> I worry about not starting from a clean checkout, since some options may
> change, and the tools won't be rebuilt.
>
> But I also worry people will complain how long the build takes.
>
> Is there a good strategy to balance these concerns?

On our project we're using an already-built binary toolchain checked
into git, which we can refresh occasionally.  I don't really like that
setup, but it does significantly reduce the overall build time.

I also severely hacked up buildroot to be able to build multiple
packages in parallel on a multicore machine; this makes builds
typically 2-3x faster on our setup, and probably even more so if you
use a really fast disk (SSD RAID?) and lots of RAM and multiple CPUs.
You can see our hacked-up version here:
http://gfiber.googlesource.com/buildroot

Beware, however, as it may burn your eyes.  Someday I would like to
clean up the parallelism patches and submit them here.

Have fun,

Avery

[Buildroot] howto incorporate buildroot into an autobuild

[Arnout Vandecappelle]

On 13/11/12 06:02, Avery Pennarun wrote:
> I also severely hacked up buildroot to be able to build multiple
> packages in parallel on a multicore machine; this makes builds
> typically 2-3x faster on our setup, and probably even more so if you
> use a really fast disk (SSD RAID?) and lots of RAM and multiple CPUs.
> You can see our hacked-up version here:
> http://gfiber.googlesource.com/buildroot
>
> Beware, however, as it may burn your eyes.  Someday I would like to
> clean up the parallelism patches and submit them here.

  Wow!  There are a couple of great ideas in that repository.  I certainly
wouldn't mind seeing some of these things upstreamed.  Like the shuffle
thing, that would be really great for the autobuilders.

  Regards,
  Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] howto incorporate buildroot into an autobuild

[Thomas Petazzoni]

Hello John,

On Mon, 12 Nov 2012 16:47:29 -0800, John Stile wrote:
> I am using buildroot for an embedded Arm project.
> 
> I was wondering how people using buildroot implement continuous
> integration builds?
> 
> Do you start from a clean checkout, build the whole tool chain (which
> takes a long time), and then build the project specific stuff?
> 
> I worry about not starting from a clean checkout, since some options may
> change, and the tools won't be rebuilt.
> 
> But I also worry people will complain how long the build takes.
> 
> Is there a good strategy to balance these concerns?

If you do continuous integration builds, do you really care that much
about the build time? Even if the build takes an hour, it is still very
reasonable for an continuous integration build system.

Tips to reduce the build time:

 * Get a fast machine. Many people complaining about build time are
   building inside a virtual machine on a slow laptop. This simply
   cannot work. Get a 4 or 8 cores machine, with 16+ GB of RAM, and
   some good I/Os.

 * Use an external toolchain.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] howto incorporate buildroot into an autobuild

[Arnout Vandecappelle]

On 13/11/12 09:45, Thomas Petazzoni wrote:
> Hello John,
>
> On Mon, 12 Nov 2012 16:47:29 -0800, John Stile wrote:
>> I am using buildroot for an embedded Arm project.
>>
>> I was wondering how people using buildroot implement continuous
>> integration builds?
>>
>> Do you start from a clean checkout, build the whole tool chain (which
>> takes a long time), and then build the project specific stuff?
>>
>> I worry about not starting from a clean checkout, since some options may
>> change, and the tools won't be rebuilt.
>>
>> But I also worry people will complain how long the build takes.
>>
>> Is there a good strategy to balance these concerns?
>
> If you do continuous integration builds, do you really care that much
> about the build time? Even if the build takes an hour, it is still very
> reasonable for an continuous integration build system.

  If you take the approach of e.g. Qt and require *every* patch to pass an
individual CI run before its accepted, then an hour is not acceptable...

> Tips to reduce the build time:
>
>   * Get a fast machine. Many people complaining about build time are
>     building inside a virtual machine on a slow laptop. This simply
>     cannot work. Get a 4 or 8 cores machine, with 16+ GB of RAM, and
>     some good I/Os.

  I don't know...  Buildroot currently serializes a lot (cfr. Avery's
remark), so going beyond 2 cores will not help that much.  It's better
to have several machines (or a single big machine) that do different
CI builds in parallel.

>   * Use an external toolchain.

  I.e. build only your toolchain with BR2_HOST_DIR set to a different path,
and use that path as an external toolchain in future builds.


  * Staggered builds. Assuming most commits are in your own software, you
can usually define a base layer that usually doesn't change.  Do a build
of this base layer once and reuse it for later builds.  Of course, you still
need to do full, clean builds occasionally.



  Regards,
  Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F