All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] lua interpreter choice?
Date: Thu, 31 Jul 2014 01:11:54 +0200	[thread overview]
Message-ID: <20140730231154.GC3961@free.fr> (raw)
In-Reply-To: <CANxTyt6GCC6K1NPyCGf9rHrO6T0o+y7K+PAioWKdRPZysDbhcA@mail.gmail.com>

Danomi, All,

On 2014-07-30 18:34 -0400, Danomi Manchego spake thusly:
> On Wed, Jul 30, 2014 at 5:40 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > Dear Danomi Manchego,
> >
> > On Wed, 30 Jul 2014 14:51:49 -0400, Danomi Manchego wrote:
> >
> >> > this change in the virtual-package behavior was introduced by
> >> > http://git.buildroot.net/buildroot/commit/?id=91169d3346e543be18139e18bdcc52a2345e0d16
> >> > (infra/pkg-virtual: validate only one provider provides an implementation)
> >> >
> >> > Fran?ois
> >>
> >> But the menuconfig still lets you select both packages, instead of
> >> providing a choice of one or the other (like "jpeg support").  Is this
> >> not undesirable?
> >
> > We discussed this before doing the commit pointed by Fran?ois.
> > Unfortunately, there's no good solution to solve this problem at the
> > kconfig level. The only solution would be to have each package being a
> > provider of a certain virtual package, have the knowledge of *all*
> > providers of that virtual packages to do a "depends
> > on !BR2_PACKAGE_<foo>". While for lua vs. luajit this seems more or
> > less reasonable, as we probably don't expect to have more providers
> > than just lua and luajit, but in the general case, we have things like
> > libgles or egl (for OpenGL support) which have multiple providers, and
> > we don't want to have to edit all of them whenever we add a new
> > provider.
> >
> > Not speaking about packages in BR2_EXTERNAL, which we cannot control.
> >
> > So our decision was to use a build-time check rather than a
> > kconfig-time check.
> >
> > Hope this clarifies the situation,
> 
> Let me apologize in advance if I'm still missing something obvious but

No problem. WE also stumbled on this issue.

> - what distinguishes the lua/luajit case from the libjpeg/jpeg-turbo
> case, or the systemd/eudev case?  Is the virtual-package
> infrastructure + kconfig choice not suitable here?

It all relates to packages in br2-external. See:
    http://nightly.buildroot.org/#outside-br-custom

Let's take an example: libEGL. libEGL is a virtual package that can be
provided by a few pacakges in Buildroot. So we, as the Buildroot
community, have the knowledge of our providers. We could technically
make a choice to select the appropriate provider, yes.

However, libEGL can also be provided by packages in BR2_EXTERNAL. For
example, there are a lot of boards with proprietary, non-public
implementations of libEGL.

ow, since we do not have the knowledge of those packages, we can't add
them to the choice. And we can't have a "dynamic" choice either.

So, for those kind of packages, we can not do better than to do a
build-time test, that the configuration is consistent.

As for lua, now. I can see your point that the two could be used at the
same time on the target. I don't see how we could solve this easily
(well, I have a very slight idea, but it's ugly.)

However, I can think that there are alternative (aka non-public,
proprietary) implementations of Lua, too, that could be used in
BR2_EXTERNAL. So, we can not offer a choice for that either.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2014-07-30 23:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-30 16:59 [Buildroot] lua interpreter choice? Danomi Manchego
2014-07-30 17:31 ` Mike Zick
2014-07-30 18:47 ` François Perrad
2014-07-30 18:51   ` Danomi Manchego
2014-07-30 21:40     ` Thomas Petazzoni
2014-07-30 22:34       ` Danomi Manchego
2014-07-30 23:11         ` Yann E. MORIN [this message]
2014-07-30 23:19         ` Yann E. MORIN
2014-07-30 23:49           ` Danomi Manchego

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=20140730231154.GC3961@free.fr \
    --to=yann.morin.1998@free.fr \
    --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.