[Buildroot] [PATCH 1/1] boot/arm-trusted-firmware: add missing host-uboot-tools select

Thomas Petazzoni thomas.petazzoni at bootlin.com
Tue Jul 23 22:30:31 UTC 2019


On Tue, 23 Jul 2019 16:24:37 +0300
Baruch Siach <baruch at tkos.co.il> wrote:

> > Well, why isn't the dependency enough in xvisor for the
> > BR2_PACKAGE_XVISOR_CREATE_UBOOT_IMAGE option?  Why isn't it enough in
> > cpio for the BR2_TARGET_ROOTFS_CPIO_UIMAGE option?  I don't know, but
> > I imagine that the answer is partially due to "truth in advertising"
> > with regards to the menu configuration (because "host uboot-tools" can
> > *appear* to be deselected but it gets built anyway if something
> > depends on it but does not select it).
> > 
> > Isn't consistency with the other places reason enough?  
> It definitely is. But usually host dependencies are not selected at the 
> Kconfig level. We have 33 matches to select.*PACKAGE_HOST_. Of these, 7 are 
> BR2_PACKAGE_HOST_UBOOT_TOOLS. On the other hand, we have thousands of make 
> level host dependencies that are not selected.
> Not sure what the rule is.

The rule is pretty much we don't care. For example, we have tons of
package that depend on host-pkgconf, but none of them select
BR2_PACKAGE_HOST_PKGCONF, even though this option exists.

All the packages using the cmake-package infrastructure use host-cmake,
but they don't select BR2_PACKAGE_HOST_CMAKE.

We have discussed several times adding in a systematic fashion
Config.in options for all host packages, and make sure they are all
selected properly, just like we do with target packages. However, last
time we discussed this, we felt the burden was way too high. For
example, all autotools-package that have AUTORECONF = YES would have to
BR2_PACKAGE_HOST_LIBTOOL. This quickly gets pretty annoying.

So for now, we've decided to stick with what we have today: a very
clear rule for target packages, and a much fuzzier situation for host

Does this clarify the unclear situation ? :-)

Best regards,

Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering

More information about the buildroot mailing list