[Buildroot] lua interpreter choice?

[Buildroot] lua interpreter choice?

[Danomi Manchego]

All,

With older buildroot releases, I was able to have lua and luajit side
by side.  After upgrading, I can *still* select both in the
menuconfig, but compiling give me:

'package/luajit/luajit.mk:75: *** Configuration error: both "luajit"
and "lua" are selected as providers for virtual package
"luainterpreter". Only one provider can be selected at a time. Please
fix your configuration.  Stop.'

I'm okay (I think) with disabling lua, as I don't *think* I need the
lighttpd "Lua support" option, which was forcing lua to be on.  If the
build will not allow both to be on then I'm wondering if, just as
libjpeg and jpeg-turbo are values for the "jpeg support" choice, if
the lua/luajit selection should be a choice rather than two separately
selectable packages?

Danomi -

[Buildroot] lua interpreter choice?

[Mike Zick]

On Wed, 30 Jul 2014 12:59:10 -0400
Danomi Manchego <danomimanchego123@gmail.com> wrote:

> All,
> 
> With older buildroot releases, I was able to have lua and luajit side
> by side.  After upgrading, I can *still* select both in the
> menuconfig, but compiling give me:
> 
> 'package/luajit/luajit.mk:75: *** Configuration error: both "luajit"
> and "lua" are selected as providers for virtual package
> "luainterpreter". Only one provider can be selected at a time. Please
> fix your configuration.  Stop.'
> 
> I'm okay (I think) with disabling lua, as I don't *think* I need the
> lighttpd "Lua support" option, which was forcing lua to be on.  If the
> build will not allow both to be on then I'm wondering if, just as
> libjpeg and jpeg-turbo are values for the "jpeg support" choice, if
> the lua/luajit selection should be a choice rather than two separately
> selectable packages?
> 

If using Lua 5.2 version code, you only need LuaJit, LuaJit-2.0.3 runs
Lua 5.2 code.

If using Lua 5.3 version code, then you need Lua-5.3 or Lua-5.2
compatability changes to your Lua 5.3 code.

I am not sure just how that relationship is handled in Buildroot.

Mike
> Danomi -
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] lua interpreter choice?

[François Perrad]

2014-07-30 18:59 GMT+02:00 Danomi Manchego <danomimanchego123@gmail.com>:
> All,
>
> With older buildroot releases, I was able to have lua and luajit side
> by side.  After upgrading, I can *still* select both in the
> menuconfig, but compiling give me:
>
> 'package/luajit/luajit.mk:75: *** Configuration error: both "luajit"
> and "lua" are selected as providers for virtual package
> "luainterpreter". Only one provider can be selected at a time. Please
> fix your configuration.  Stop.'
>

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

> I'm okay (I think) with disabling lua, as I don't *think* I need the
> lighttpd "Lua support" option, which was forcing lua to be on.  If the
> build will not allow both to be on then I'm wondering if, just as
> libjpeg and jpeg-turbo are values for the "jpeg support" choice, if
> the lua/luajit selection should be a choice rather than two separately
> selectable packages?
>
> Danomi -
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] lua interpreter choice?

[Danomi Manchego]

On Wed, Jul 30, 2014 at 2:47 PM, Fran?ois Perrad
<francois.perrad@gadz.org> wrote:
> 2014-07-30 18:59 GMT+02:00 Danomi Manchego <danomimanchego123@gmail.com>:
>> All,
>>
>> With older buildroot releases, I was able to have lua and luajit side
>> by side.  After upgrading, I can *still* select both in the
>> menuconfig, but compiling give me:
>>
>> 'package/luajit/luajit.mk:75: *** Configuration error: both "luajit"
>> and "lua" are selected as providers for virtual package
>> "luainterpreter". Only one provider can be selected at a time. Please
>> fix your configuration.  Stop.'
>>
>
> 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

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?

Danomi -


>> I'm okay (I think) with disabling lua, as I don't *think* I need the
>> lighttpd "Lua support" option, which was forcing lua to be on.  If the
>> build will not allow both to be on then I'm wondering if, just as
>> libjpeg and jpeg-turbo are values for the "jpeg support" choice, if
>> the lua/luajit selection should be a choice rather than two separately
>> selectable packages?
>>
>> Danomi -
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] lua interpreter choice?

[Thomas Petazzoni]

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,

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

[Buildroot] lua interpreter choice?

[Danomi Manchego]

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?

Danomi -

[Buildroot] lua interpreter choice?

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] lua interpreter choice?

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] lua interpreter choice?

[Danomi Manchego]

Yann, and all,

I have a better understanding now.  Thanks for the explanations.

Danomi -


On Wed, Jul 30, 2014 at 7:19 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> 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.  |
> '------------------------------^-------^------------------^--------------------'