From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] virtual-packages: the case for multiple providers selected
Date: Tue, 13 May 2014 22:05:54 +0200 [thread overview]
Message-ID: <20140513220554.78579296@free-electrons.com> (raw)
In-Reply-To: <20140513180945.GC3507@free.fr>
Hello,
On Tue, 13 May 2014 20:09:45 +0200, Yann E. MORIN wrote:
> Two options have been proposed by Thomas P. on IRC:
>
> - add a choice to select one and only provider at a time, and make all
> the providers prompt-less config options so it is not possible to
> choose more than one at a time;
>
> - add a pre-build check that verifies that not two providers of the
> same feature are selected, and bail out early in the build if that
> is the case.
>
> Both of those options have issues.
>
> - going with the choice means that it is no longer possible to add a
> new provider in BR2_EXTERNAL without changing the Buildroot source
> tree, one of the main selling-point of BR2_EXTERNAL to begin with,
I don't agree that it's the main selling point of BR2_EXTERNAL. The
main selling point was the ability to have package .mk files outside of
the main Buildroot tree. Which remains entirely possible. The only
limitation that a choice introduces is that such an out-of-tree
package .mk file cannot implement a provider for an in-tree virtual
package, without making an in-tree change. It is certainly less nice
than it was, but it clearly doesn't make BR2_EXTERNAL useless at all.
> - going with the check means that it will still possible to generate
> such configurations, which means we'd still get autobuild failures
> for those (unless the autobuilders are tweaked to recognise this,)
> while it would be a minimal annoyance to the user.
Right, for the autobuilders, it would be a bit annoying. We could also
decide to ignore the problem completely, and have the autobuilder
script reject random configurations that have multiple providers
selected for a given virtual package. I however don't really see how to
implement that in a generic fashion, so we would have to have an
explicit list of all possible providers for all virtual packages.
> I am rather opposed to this, since I believe allowing providers from
> BR2_EXTERNAL is a requirement for BR2_EXTERNAL, and we do want to
> support this situation. After all, I can easily see a BR2_EXTERNAL tree
> with proprietary, non-public providers for 3d and/or video-decoding
> hardware acceleration.
That use case is indeed true.
> On the other hand, kconfig does not expose the number of config item
> that select another one, e.g. it is not possible to know how many
> packages did 'select HAS_EGL', we'd have to resort to the .mk to do the
> calculations and the check. I think this should be doable in a
> relatively non-invasive way, with some Makefile trickery.
>
> So, what do you guys think of these two proposals? Do you have an
> alternate solution to propose?
The third option is the one I exposed earlier: do nothing, and work
around the problem in the autobuilder scripts.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2014-05-13 20:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-13 18:09 [Buildroot] virtual-packages: the case for multiple providers selected Yann E. MORIN
2014-05-13 20:05 ` Thomas Petazzoni [this message]
2014-05-13 20:12 ` Thomas De Schampheleire
2014-05-13 20:18 ` Thomas Petazzoni
2014-05-14 7:21 ` Thomas De Schampheleire
2014-05-14 7:30 ` Thomas Petazzoni
2014-05-14 7:34 ` Thomas De Schampheleire
2014-05-14 7:36 ` Thomas Petazzoni
2014-05-13 21:47 ` [Buildroot] [PATCH] infra/pkg-virtual: validate only one provider provides an implementation Yann E. MORIN
2014-05-13 22:05 ` Thomas Petazzoni
2014-05-13 22:14 ` Yann E. MORIN
2014-05-14 8:10 ` Arnout Vandecappelle
2014-05-14 17:35 ` Yann E. MORIN
2014-05-14 8:11 ` [Buildroot] virtual-packages: the case for multiple providers selected Arnout Vandecappelle
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=20140513220554.78579296@free-electrons.com \
--to=thomas.petazzoni@free-electrons.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.