From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v3 1/3] package/waf: add a blind Config.in.host
Date: Thu, 3 Jan 2019 22:50:52 +0100 [thread overview]
Message-ID: <20190103225052.3feb76c6@windsurf> (raw)
In-Reply-To: <20181226215521.GL14286@scaer>
Hello,
+Arnout in Cc. Arnout, there's some discussion on one of your favorite
topic: Config.in.host options for all packages. Read on below.
On Wed, 26 Dec 2018 22:55:21 +0100, Yann E. MORIN wrote:
> > I.e: I am all in favor of this change, but I'm just curious to
> > understand why you did it in the first place.
>
> Well, I am not really happy with that, though: do we really plan on
> having packages really select all the host tools they need?
>
> If so, do we really envision autotools-based packages selecting
> host-autoconf, host-automake, host-libtool? And then packages that use
> host-pkgconf you should also select it...
>
> Also, what about host-cmake, which is conditionally built, but for which
> we do not have the info in kconfig? (well, we can argue we'd have to do
> like we do for host-gcc, but still). Oh, and host-tar, host-flex,
> host-bison, and so on... :-/
Meh, I hadn't thought of conditional packages like host-tar, host-cmake
and so on.
> So, no, I'm not happy with that direction...
>
> config BR2_PACKAGE_FOO
> bool "foo"
> select BR2_PACKAGE_HOST_AUTOCONF
> select BR2_PACKAGE_HOST_AUTOMAKE
> select BR2_PACKAGE_HOST_LIBTOOL
> select BR2_PACKAGE_MAYBE_HOST_TAR
> select BR2_PACKAGE_MAYBE_HOST_FLEX_FOR_KCONFIG
> select BR2_PACKAGE_MAYBE_HOST_BISON_FOR_KCONFIG
> select BR2_PACKAGE_HOST_PKGCONF
>
> Unles we're planning on hiding that away into meta-config, like:
>
> config BR2_PACKAGE_FOO
> bool "foo"
> select BR2_AUTOTOOLS_PACKAGE # mimick $(eval $(autotools-package))
> select BR2_PACKAGE_HOST_PKGCONF_BECAUSE_IT_S_NOT_MANDATORY
>
> And still, the optionally-required host packages like tar, flex et al.
> are not covered...
>
> Meh... :-(
Indeed, I understand the "Meh" here. I hadn't really realized what it
would mean to have Config.in.host options for all packages, and
properly selected by all its users.
But still, there are a number of cases where it would really help, so
that a given host package can be aware that another host package has
been built with a given feature (or not). Or precisely to force that a
certain host package is built with a given option. For example, in
host-python, we had situations where only a given package needed
host-python to be built with FOO support, and since we don't have any
BR2_PACKAGE_HOST_PYTHON_FOO option, our only choice was to
unconditionally enable FOO support in host-python, adding build time to
everyone, even if FOO in host-python might only be needed for one
obscure package.
It seems like we don't have a very conclusive decision on this topic at
this point.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2019-01-03 21:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-23 17:19 [Buildroot] [PATCH v3 1/3] package/waf: add a blind Config.in.host Carlos Santos
2018-12-23 17:19 ` [Buildroot] [PATCH v3 2/3] doc/manual: document the waf packages may need to select host-waf Carlos Santos
2018-12-26 21:31 ` Thomas Petazzoni
2018-12-23 17:19 ` [Buildroot] [PATCH v3 3/3] package/mpv: selec host-waf Carlos Santos
2018-12-26 21:30 ` [Buildroot] [PATCH v3 1/3] package/waf: add a blind Config.in.host Thomas Petazzoni
2018-12-26 21:55 ` Yann E. MORIN
2019-01-03 21:50 ` Thomas Petazzoni [this message]
2019-01-03 22:06 ` Yann E. MORIN
2019-01-03 22:14 ` Yann E. MORIN
2019-01-03 23:34 ` Carlos Santos
2019-01-04 8:58 ` Thomas Petazzoni
2019-01-04 10:05 ` Carlos Santos
2019-01-04 10:10 ` Thomas Petazzoni
2019-01-04 11:06 ` Arnout Vandecappelle
2019-01-04 11:51 ` Yann E. MORIN
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=20190103225052.3feb76c6@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.