From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] lua interpreter choice?
Date: Thu, 31 Jul 2014 01:19:35 +0200 [thread overview]
Message-ID: <20140730231935.GD3961@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
> - 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 just occured to me that I only replied to half your questions.
As for libjpeg/jpeg-turbo: the choice was pre-existing before the
virtual package infra was added. It was decide to keep them as-is,
rather than to fully convert them.
As for eudev vs. systemd: they are not really a choice og one _or_ tghe
other, since you can still have none. Besides, they are not the same
thing: systemd is an init system, daemon; eudev is a /dev management
system. So we do really need choices here, because what we're selecting
is not a provider of a virtual package, but an init system or a /dev
management system. It happens that both are also providers of udev.
Hopefully this further clarifies the situation.
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. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2014-07-30 23:19 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
2014-07-30 23:19 ` Yann E. MORIN [this message]
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=20140730231935.GD3961@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.