From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] boot/arm-trusted-firmware: add missing host-uboot-tools select
Date: Wed, 24 Jul 2019 00:30:31 +0200 [thread overview]
Message-ID: <20190724003031.39c99f92@windsurf> (raw)
In-Reply-To: <20190723132437.niyaqas7gezbe6mp@sapphire.tkos.co.il>
Hello,
On Tue, 23 Jul 2019 16:24:37 +0300
Baruch Siach <baruch@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
select BR2_PACKAGE_HOST_AUTOCONF, BR2_PACKAGE_HOST_AUTOMAKE and
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
packages.
Does this clarify the unclear situation ? :-)
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
prev parent reply other threads:[~2019-07-23 22:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-23 1:34 [Buildroot] [PATCH 1/1] boot/arm-trusted-firmware: add missing host-uboot-tools select Danomi Manchego
2019-07-23 4:02 ` Baruch Siach
2019-07-23 12:16 ` Danomi Manchego
2019-07-23 13:24 ` Baruch Siach
2019-07-23 22:30 ` Thomas Petazzoni [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190724003031.39c99f92@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox