Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] virtual-packages: the case for multiple providers selected
Date: Wed, 14 May 2014 09:30:14 +0200	[thread overview]
Message-ID: <20140514093014.315bd371@free-electrons.com> (raw)
In-Reply-To: <CAAXf6LXa0MRtnb8xQ266J+O1Tp5BkWzVWJP7C3aYZCGbx8gd0w@mail.gmail.com>

Dear Thomas De Schampheleire,

On Wed, 14 May 2014 09:21:33 +0200, Thomas De Schampheleire wrote:

> tdescham at argentina ~/repo/contrib/buildroot-bugs $ hg diff
> diff --git a/Config.in b/Config.in
> --- a/Config.in
> +++ b/Config.in
> @@ -369,6 +369,9 @@ config BR2_STRIP_none
>         help
>           Do not strip binaries and libraries in the target
>           filesystem.
> +
> +source "$BR2_EXTERNAL/test.in"
> +
>  endchoice
> 
>  config BR2_STRIP_EXCLUDE_FILES
> diff --git a/support/dummy-external/test.in b/support/dummy-external/test.in
> new file mode 100644
> --- /dev/null
> +++ b/support/dummy-external/test.in
> @@ -0,0 +1,2 @@
> +config BR2_STRIP_test
> +       bool "test"
> 
> 
> test.in would either exist in dummy-external, or in BR2_EXTERNAL, so
> there is no problem of missing files.
> It requires a separate file in BR2_EXTERNAL that has to be present if
> you choose to use BR2_EXTERNAL, but can be empty. Moreover, you need
> one such file for each choice you want to expand this way.
> I'm leaning more towards the preflight check, but I just want to
> highlight that expanding a choice from BR2_EXTERNAL is effectively
> possible.

Then it means that as soon as you define a BR2_EXTERNAL value, it
*must* point to a directory containing all the "<foo>.in" files for all
possible virtual packages that Buildroot has. This really doesn't seem
nice.

Remember, we're not talking about *one* choice option here, we're
talking about one *per* virtual package: one for EGL, one for OpenVG,
one for OpenGLES, one for OpenGL, one for ..., one for ...

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

  reply	other threads:[~2014-05-14  7:30 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
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 [this message]
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=20140514093014.315bd371@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox