[Buildroot] Report from the Buildroot Developer Day, 29th October 2010

Thomas De Schampheleire patrickdepinguin+buildroot at gmail.com
Fri Nov 26 12:16:45 UTC 2010


On Tue, Nov 23, 2010 at 10:14 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Board cleanup
> =============
> Nicolas and Patrice, who ship Buildroot as one of the development
> environment for the AT91 Atmel evaluation boards, were generally
> satisfied with those changes.
> They however, proposed some improvements:
>  * Add the ability for some key components (kernel, u-boot, etc.) to
>   specify a patch that is in fact a tarball containing multiple
>   patches, stored on http/ftp. This is more practical than the
>   current situation of a single file patch, since most of the time,
>   series of patches needs to be applied.
>  * Add the ability to specify a space-separated list of patches.
> Thomas has voluntered to implement those two changes for the 2011.02
> release.

What about allowing components to be located in a separate location,
outside of buildroot?

For example, I currently have a custom linux kernel, that I would like
to use in buildroot. I selected the 'custom' kernel options, and
placed the .tar.bz2 file containing the custom kernel in the 'dl'
directory of buildroot. This works.

Unfortunately, since the custom kernel is under development, I
regularly need to make changes to it. My current approach forces me to
create a new .tar.bz2 archive every time I want to create a build with
the changed kernel.

Another solution would be to create patches each time I create a
build, and specify the patches in buildroot (using one of the proposed
improvements above), but still it requires me to do manual work.

It would be interesting to have a feature that allows one to specify a
path to an (unpacked) kernel. Buildroot would then directly use this
path as the source base, but would place the output files elsewhere
(in the output directory of buildroot).
Each time I modify the sources, buildroot should automatically (and
this is the hard part) determine it should rebuild them, but I don't
need to manually create an archive or patches.


More information about the buildroot mailing list