add host arch detection and Kconfig BR2_HOSTARCH

This will allow to install binary package only if they are supported by the host. As example Atmel SAM-BA (x86 only).

Signed-off-by Jean-Christophe PLAGNIOL-VILLARD <[email protected]>

Le Wed, 18 Jul 2012 15:59:09 +0200,
Francois Perrad <[email protected]> a ?crit :

Quoted 4 lines

This will allow to install binary package only if they are supported by the host. As example Atmel SAM-BA (x86 only).

Signed-off-by Jean-Christophe PLAGNIOL-VILLARD <[email protected]>

I have applied this patch and the 3 other Lua-related patches.

Could you however work on something that ensures that the BR2_PACKAGE_LUA option, when enabled, actually installs something? Maybe the BR2_PACKAGE_LUA_SHARED_LIBRARY option needs to be removed, and just enabling BR2_PACKAGE_LUA should unconditionally install the shared library. Sub-options could be used to selectively install the interpreter and/or the compiler. Do you think it makes sense?

Another thing that would be great is probably to rename all Lua modules to lua<something>, like luaexpat and luacjson. Do you think it is possible? The only drawback is probably that the package name would no longer match the upstream project name, but it would make Lua modules much easier to identify in the list of packages in package/.

Thanks,

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Quoted 6 lines

Could you however work on something that ensures that the BR2_PACKAGE_LUA option, when enabled, actually installs something? Maybe the BR2_PACKAGE_LUA_SHARED_LIBRARY option needs to be removed, and just enabling BR2_PACKAGE_LUA should unconditionally install the shared library. Sub-options could be used to selectively install the interpreter and/or the compiler. Do you think it makes sense?

have you reconsidered this outdated patch
http://article.gmane.org/gmane.comp.lib.uclibc.buildroot/43210 ?

Quoted 6 lines

Another thing that would be great is probably to rename all Lua modules to lua<something>, like luaexpat and luacjson. Do you think it is possible? The only drawback is probably that the package name would no longer match the upstream project name, but it would make Lua modules much easier to identify in the list of packages in package/.

Lua modules use one of following schemes :
foo, Foo, lfoo, LFoo, luafoo, LuaFoo, lua-foo, lua-Foo, Lua-Foo,
foo-lua, foo-lua, foolua, FooLua
See real world examples in these 2 Lua package managers :
- LuaRocks : http://luarocks.org/repositories/rocks/
- LuaDist : https://github.com/LuaDist/Repository

Native binding are compatible Lua/LuaJIT, but the recent LuaJIT FFI allows to write libraries binding in pure Lua.
So, there are too http://wiki.luajit.org/FFI-Bindings, with more schemes.

my first choice is to move all Lua modules in a directory 'lua-modules' (and for future use, a directory 'luajit-ffi').
you already tell me that it is not the BR policy.
I agree that the directory 'multimedia' is a bad thing.
I think that it is a good way for framework like 'efl', 'x11r7'. So, I think that it is the good way for interpreted languages like lua when there are a lot of modules.
(see in attachment a Perl script which does the move,
I write it for this old ticket https://bugs.busybox.net/show_bug.cgi?id=2419)

my second choice is to use the upstream name, like now. a Lua user could see the list of modules with [menu|g|k]config or in a well identified section of package/Config.in.

Le Thu, 19 Jul 2012 14:48:52 +0200,
Fran?ois Perrad <[email protected]> a ?crit :

Quoted 7 lines

Quoted 6 lines

Could you however work on something that ensures that the BR2_PACKAGE_LUA option, when enabled, actually installs something? Maybe the BR2_PACKAGE_LUA_SHARED_LIBRARY option needs to be removed, and just enabling BR2_PACKAGE_LUA should unconditionally install the shared library. Sub-options could be used to selectively install the interpreter and/or the compiler. Do you think it makes sense?

Quoted 2 lines

have you reconsidered this outdated patch
http://article.gmane.org/gmane.comp.lib.uclibc.buildroot/43210 ?

I maintain the comment I'm making above: I think the BR2_PACKAGE_LUA_SHARED_LIBRARY option should completely be removed. So with this in mind, the patch you're pointing to doesn't make sense.

Quoted 18 lines

Quoted 6 lines

Another thing that would be great is probably to rename all Lua modules to lua<something>, like luaexpat and luacjson. Do you think it is possible? The only drawback is probably that the package name would no longer match the upstream project name, but it would make Lua modules much easier to identify in the list of packages in package/.

Lua modules use one of following schemes :
foo, Foo, lfoo, LFoo, luafoo, LuaFoo, lua-foo, lua-Foo, Lua-Foo,
foo-lua, foo-lua, foolua, FooLua
See real world examples in these 2 Lua package managers :
- LuaRocks : http://luarocks.org/repositories/rocks/
- LuaDist : https://github.com/LuaDist/Repository

Native binding are compatible Lua/LuaJIT, but the recent LuaJIT FFI allows to write libraries binding in pure Lua.
So, there are too http://wiki.luajit.org/FFI-Bindings, with more schemes.

Quoted 9 lines

my first choice is to move all Lua modules in a directory 'lua-modules' (and for future use, a directory 'luajit-ffi').
you already tell me that it is not the BR policy.
I agree that the directory 'multimedia' is a bad thing.
I think that it is a good way for framework like 'efl', 'x11r7'. So, I think that it is the good way for interpreted languages like lua when there are a lot of modules.
(see in attachment a Perl script which does the move,
I write it for this old ticket https://bugs.busybox.net/show_bug.cgi?id=2419)

Yes, I know Peter wanted to have all the packages at the top-level. I was skeptical with this choice at the beginning, but now I find it more and more useful. Try to find a package in OpenEmbedded for example:
they are organized in sub-directories, and it's really a pain to find where your package is. Even in the menuconfig these days, I often have to use the search engine to find certain packages for which the category isn't obvious (example: 'gettext' in 'Development tools').

As I'm only an interim maintainer, I don't want to bypass Peter on this decision. Also, what is the opinion of the other members of the community?

Quoted 3 lines

my second choice is to use the upstream name, like now. a Lua user could see the list of modules with [menu|g|k]config or in a well identified section of package/Config.in.

Yes. It is also not so bad.

Best regards,

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

take as example a target with luajit and luasocket. nothing from lua is needed at runtime.
but at compile time of luasocket, include files from lua (lua.h, luaconf.h, lualib.h, lauxlib.h) are mandatory in staging. so, luasocket.mk contains : LUASOCKET_DEPENDENCIES = lua

so, it is useful that BR2_PACKAGE_LUA installs nothing on target. the 3 sub-options BR2_PACKAGE_LUA_COMPILER, BR2_PACKAGE_LUA_INTERPRETER and BR2_PACKAGE_LUA_SHARED_LIBRARY are install flags (as said in there help doc).
so, BR2_PACKAGE_LUA_SHARED_LIBRARY shouldn't be removed.

Le Fri, 20 Jul 2012 13:40:14 +0200,
Fran?ois Perrad <[email protected]> a ?crit :

Quoted 11 lines

take as example a target with luajit and luasocket. nothing from lua is needed at runtime.
but at compile time of luasocket, include files from lua (lua.h, luaconf.h, lualib.h, lauxlib.h) are mandatory in staging. so, luasocket.mk contains : LUASOCKET_DEPENDENCIES = lua

so, it is useful that BR2_PACKAGE_LUA installs nothing on target. the 3 sub-options BR2_PACKAGE_LUA_COMPILER, BR2_PACKAGE_LUA_INTERPRETER and BR2_PACKAGE_LUA_SHARED_LIBRARY are install flags (as said in there help doc).
so, BR2_PACKAGE_LUA_SHARED_LIBRARY shouldn't be removed.

So this means luajit is not a complete replacement for lua?

Note that you did:

if BR2_PACKAGE_LUA || BR2_PACKAGE_LUAJIT
menu "LUA libraries/modules"
source "package/cgilua/Config.in"
source "package/copas/Config.in"
source "package/coxpcall/Config.in"
source "package/luacjson/Config.in"
source "package/luaexpat/Config.in"
source "package/luafilesystem/Config.in"
source "package/luasocket/Config.in"
source "package/rings/Config.in"
source "package/wsapi/Config.in"
source "package/xavante/Config.in"
endmenu

So this means that Lua modules can currently be compiled without the Lua package being selected. Of course, the Lua package will be built because the Lua modules packages depend on it (in terms of .mk), but that's really not how things are supposed to work.

Thomas

--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

LuaJIT was designed to operate with modules compiled with Lua 5.1 includes.

But LuaJIT supplies also its own set of includes (in /usr/include/luajit-2.0).

So, each Lua module could be modified with the following pattern :

    ifeq ($(BR2_PACKAGE_LUA),y)
        LUAFOO_DEPENDENCIES = lua
        LUAFOO_INCLUDES = $(STAGING_DIR)/usr/include
    else
        LUAFOO_DEPENDENCIES = luajit
        LUAFOO_INCLUDES = $(STAGING_DIR)/usr/include/luajit-2.0
    endif

instead of the current : LUAFOO_DEPENDENCIES = lua