| Message ID | 1342619953-15512-1-git-send-email-francois.perrad@gadz.org |
|---|---|
| State | Accepted |
| Headers | show |
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
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
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
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
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
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
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
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:
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(+)