[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