Patchwork [1/4] add host arch detection and Kconfig BR2_HOSTARCH

login
register
mail settings
Submitter Francois Perrad
Date July 18, 2012, 1:59 p.m.
Message ID <1342619953-15512-1-git-send-email-francois.perrad@gadz.org>
Download mbox | patch
Permalink /patch/171679/
State Accepted
Headers show

Comments

Francois Perrad - July 18, 2012, 1:59 p.m.
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 <plagnioj@jcrosoft.com>
---
 Config.in |    4 ++++
 Makefile  |   10 ++++++++++
 2 files changed, 14 insertions(+)
Thomas Petazzoni - July 18, 2012, 5:37 p.m.
Le Wed, 18 Jul 2012 15:59:09 +0200,
Francois Perrad <fperrad@gmail.com> a écrit :

> 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 <plagnioj@jcrosoft.com>

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
Francois Perrad - July 19, 2012, 12:48 p.m.
2012/7/18 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Le Wed, 18 Jul 2012 15:59:09 +0200,
> Francois Perrad <fperrad@gmail.com> a écrit :
>
>> 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 <plagnioj@jcrosoft.com>
>
> 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?
>

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

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

François

> 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@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
Thomas Petazzoni - July 19, 2012, 1:03 p.m.
Le Thu, 19 Jul 2012 14:48:52 +0200,
François Perrad <francois.perrad@gadz.org> a écrit :

> > 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 ?

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.

> > 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)

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?

> 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
Francois Perrad - July 20, 2012, 11:40 a.m.
2012/7/19 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Le Thu, 19 Jul 2012 14:48:52 +0200,
> François Perrad <francois.perrad@gadz.org> a écrit :
>
>> > 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 ?
>
> 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.
>

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.

François

>> > 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)
>
> 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?
>
>> 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
Thomas Petazzoni - July 20, 2012, 12:14 p.m.
Le Fri, 20 Jul 2012 13:40:14 +0200,
François Perrad <francois.perrad@gadz.org> a écrit :

> 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
Francois Perrad - July 20, 2012, 6:24 p.m.
2012/7/20 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>:
> Le Fri, 20 Jul 2012 13:40:14 +0200,
> François Perrad <francois.perrad@gadz.org> a écrit :
>
>> 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

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

Currently, I prefer the shortest pattern.

François

> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
Thomas Petazzoni - July 20, 2012, 6:41 p.m.
Le Fri, 20 Jul 2012 20:24:27 +0200,
François Perrad <francois.perrad@gadz.org> a écrit :

> 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 apparently, we could see lua and luajit as two mutually exclusive
packages.

> 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

Or we could do something like:

 (*) lua and luajit are mutually exclusive packages

 (*) Some common .mk file does something like:

ifeq ($(BR2_PACKAGE_LUA),y)
LUA_INTERPRETER = lua
else ifeq ($(BR2_PACKAGE_LUAJIT),y)
LUA_INTERPRETER = luajit
endif

 (*) luajit would install its headers in $(STAGING_DIR)/usr/include, so
 that it is transparent whether lua or luajit is used, from the modules
 point of view

 (*) Lua modules would do LUAFOO_DEPENDENCIES = $(LUA_INTERPRETER)

Or something along those lines.

Essentially, we have a similar sort of problem for jpeg-turbo, which is
a drop-in replacement for libjpeg, and we don't really know how to
handle that properly in BR today.

Best regards,

Thomas

Patch

diff --git a/Config.in b/Config.in
index 925c247..c182f70 100644
--- a/Config.in
+++ b/Config.in
@@ -10,6 +10,10 @@  config BR2_VERSION
 	string
 	option env="BR2_VERSION_FULL"
 
+config BR2_HOSTARCH
+	string
+	option env="HOSTARCH"
+
 source "target/Config.in.arch"
 
 menu "Build options"
diff --git a/Makefile b/Makefile
index d55b136..639fdaa 100644
--- a/Makefile
+++ b/Makefile
@@ -32,6 +32,16 @@  ifneq ($(firstword $(sort $(MAKE_VERSION) $(MIN_MAKE_VERSION))),$(MIN_MAKE_VERSI
 $(error You have make '$(MAKE_VERSION)' installed. GNU make >= $(MIN_MAKE_VERSION) is required)
 endif
 
+export HOSTARCH := $(shell uname -m | \
+	sed -e s/i.86/x86/ \
+	    -e s/sun4u/sparc64/ \
+	    -e s/arm.*/arm/ \
+	    -e s/sa110/arm/ \
+	    -e s/ppc64/powerpc/ \
+	    -e s/ppc/powerpc/ \
+	    -e s/macppc/powerpc/\
+	    -e s/sh.*/sh/)
+
 # This top-level Makefile can *not* be executed in parallel
 .NOTPARALLEL: