[Buildroot] [PATCH v10 01/28] package/efl/libefl: new package
Romain Naour
romain.naour at openwide.fr
Thu Dec 17 22:09:33 UTC 2015
Hi Thomas, Yann, All,
Le 16/12/2015 21:32, Thomas Petazzoni a écrit :
> Romain,
>
> On Tue, 15 Dec 2015 23:40:13 +0100, Romain Naour wrote:
>
>> Also, add BR2_PACKAGE_LIBEFL_RECOMMENDED_CONFIG config option in order to
>> select all recommended packages that allows to build libefl without the
>> extra-long --enable-i-really-know-what-i-am-doing...
>
> I am still not entirely happy with your recommended config mechanism.
> What I want to see is the visible option "recommended config"
> completely removed. See my proposal in the attached patch 0001.
>
> My attached patch 0002 also rewraps some Config.in help text.
ok, I'll merge these two patches. Thanks.
>
> But I have more issues, see below.
>
>
>> diff --git a/package/efl/Config.in b/package/efl/Config.in
>> index 7ce5a36..3a5e708 100644
>> --- a/package/efl/Config.in
>> +++ b/package/efl/Config.in
>> @@ -1,8 +1,13 @@
>> menuconfig BR2_PACKAGE_EFL
>> bool "Enlightenment Foundation Libraries"
>> - depends on BR2_USE_WCHAR
>> - # libeina uses madvise(). To revisit when bumping EFL to 1.8
>> + depends on BR2_INSTALL_LIBSTDCPP
>> + depends on BR2_PACKAGE_HAS_UDEV # libudev
>> + depends on BR2_PACKAGE_LUA # lua 5.1 or better
>
> So we really need Lua itself, and not LuaJIT ? If we need only Lua (and
> not LuaJIT), why don't we select it ? If we can use either Lua or
> LuaJIT, then we should "depends on BR2_PACKAGE_LUAINTERPRETER.
>
> Also, if I apply just this patch, I get some kconfig warnings:
>
> package/efl/Config.in:1:error: recursive dependency detected!
> package/efl/Config.in:1: symbol BR2_PACKAGE_EFL depends on BR2_PACKAGE_LUA
> package/lua/Config.in:1: symbol BR2_PACKAGE_LUA is selected by BR2_PACKAGE_LIBEDJE
> package/efl/libedje/Config.in:4: symbol BR2_PACKAGE_LIBEDJE is selected by BR2_PACKAGE_LIBETHUMB
> package/efl/libethumb/Config.in:4: symbol BR2_PACKAGE_LIBETHUMB depends on BR2_PACKAGE_EFL
>
> But it's true that your series later removes libedje, so maybe I should
> just not care about this: it's hard to do the big change you're doing
> without having some intermediate steps that are imperfect.
Well, I tried to do a smooth update series has much as possible ;-)
But I didn't want to modify efl packages that are removed at the end of the
series... I didn't test all intermediate test of this series, only when the
entire series is applied.
>
> Can you let me know the answer for the Lua/LuaJIT question so that we
> can move forward with this ?
I haven't tested all lua interpreter...
Here is the lua interpreter I used for the runtime test:
BR2_PACKAGE_LUA=y
BR2_PACKAGE_PROVIDES_LUAINTERPRETER="lua"
BR2_PACKAGE_LUA_5_1=y
If you want to try with LuaJIT, the --enable-lua-old option must be removed.
IIRC, I had some build issue with it but it was with efl 1.13.2.
So, I wanted to avoid LuaJIT for now and be sure that one of LUA packages is
selected.
I'll check if efl can just depends on BR2_PACKAGE_HAS_LUAINTERPRETER.
Best regards,
Romain
>
> Thanks!
>
> Thomas
>
More information about the buildroot
mailing list