[Buildroot] [RFC v3 00/30] Add per-package staging feature

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Tue Mar 3 14:21:21 UTC 2015


Dear Fabio Porcedda,

On Tue, 3 Mar 2015 15:03:46 +0100, Fabio Porcedda wrote:

> > Could you give some hints about the performance impact of those copies
> > of the staging directory? Does it continue to make the top-level
> > parallel build thing useful?
> 
> IMHO the per-package staging feature is useful even without taking in
> consideration the top-level parallel build, the unspecified optional
> dependency issue are not common, they can generate build faulres or
> just binary with unexpected behavior.

Yes, correct, this is indeed another benefit of this approach.

> > Preferably something with a fairly deep dependency tree, i.e lots of
> > small packages that depend on each other. A X.org stack + gtk2 would be
> > a good example.
> 
> The most complete selection of package that i've tested is the
> defconfig + allyespacakgeconfig (693 targets), i've tried to enable a
> wider range of packages, defconfig + glibc + allyespackageconfig but
> even without using the pps they fail to build.
> So i will provide build times of the configuration defconfig +
> allyespackageconfig.

Ok.

> If you provide a defconfig on the release 2015.02, i can try to build that.

Something like:

BR2_arm=y
BR2_TOOLCHAIN_BUILDROOT_LARGEFILE=y
BR2_TOOLCHAIN_BUILDROOT_INET_IPV6=y
BR2_TOOLCHAIN_BUILDROOT_INET_RPC=y
BR2_TOOLCHAIN_BUILDROOT_LOCALE=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PACKAGE_XORG7=y
BR2_PACKAGE_XSERVER_XORG_SERVER=y
BR2_PACKAGE_LIBGTK3=y

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com



More information about the buildroot mailing list