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

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

[Francois Perrad]

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

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:
 
-- 
1.7.9.5

[Buildroot] [PATCH 2/4] luajit: new package

[Francois Perrad]

Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
---
 package/Config.in                             |    3 +-
 package/luajit/Config.in                      |   10 ++++
 package/luajit/luajit-01-root-path.patch      |   22 +++++++++
 package/luajit/luajit-02-shared-lib.patch     |   17 +++++++
 package/luajit/luajit-03-dont-strip.patch     |   23 ++++++++++
 package/luajit/luajit-04-no-bin-symlink.patch |   40 ++++++++++++++++
 package/luajit/luajit.mk                      |   61 +++++++++++++++++++++++++
 7 files changed, 175 insertions(+), 1 deletion(-)
 create mode 100644 package/luajit/Config.in
 create mode 100644 package/luajit/luajit-01-root-path.patch
 create mode 100644 package/luajit/luajit-02-shared-lib.patch
 create mode 100644 package/luajit/luajit-03-dont-strip.patch
 create mode 100644 package/luajit/luajit-04-no-bin-symlink.patch
 create mode 100644 package/luajit/luajit.mk

diff --git a/package/Config.in b/package/Config.in
index 8529777..6aabb8e 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -245,7 +245,8 @@ endmenu
 menu "Interpreter languages and scripting"
 source "package/haserl/Config.in"
 source "package/lua/Config.in"
-if BR2_PACKAGE_LUA
+source "package/luajit/Config.in"
+if BR2_PACKAGE_LUA || BR2_PACKAGE_LUAJIT
 menu "LUA libraries/modules"
 source "package/cgilua/Config.in"
 source "package/copas/Config.in"
diff --git a/package/luajit/Config.in b/package/luajit/Config.in
new file mode 100644
index 0000000..4a6bcdf
--- /dev/null
+++ b/package/luajit/Config.in
@@ -0,0 +1,10 @@
+config BR2_PACKAGE_LUAJIT
+	bool "luajit"
+	depends on BR2_i386 || (BR2_x86_64 && BR2_HOSTARCH='x86_64') || BR2_powerpc || BR2_arm || BR2_armeb
+	help
+	  LuaJIT implements the full set of language features defined
+	  by Lua 5.1. The virtual machine (VM) is API- and
+	  ABI-compatible to the standard Lua interpreter and can be
+	  deployed as a drop-in replacement.
+
+	  http://luajit.org/
diff --git a/package/luajit/luajit-01-root-path.patch b/package/luajit/luajit-01-root-path.patch
new file mode 100644
index 0000000..3b0a585
--- /dev/null
+++ b/package/luajit/luajit-01-root-path.patch
@@ -0,0 +1,22 @@
+Adjust installation location to /usr
+
+Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+Index: b/src/luaconf.h
+===================================================================
+--- a/src/luaconf.h
++++ b/src/luaconf.h
+@@ -22,9 +22,9 @@
+ #define LUA_CPATH_DEFAULT \
+   ".\\?.dll;" LUA_CDIR"?.dll;" LUA_CDIR"loadall.dll"
+ #else
+-#define LUA_ROOT	"/usr/local/"
+-#define LUA_LDIR	LUA_ROOT "share/lua/5.1/"
+-#define LUA_CDIR	LUA_ROOT "lib/lua/5.1/"
++#define LUA_ROOT	"/usr/"
++#define LUA_LDIR	LUA_ROOT "share/lua/"
++#define LUA_CDIR	LUA_ROOT "lib/lua/"
+ #ifdef LUA_XROOT
+ #define LUA_JDIR	LUA_XROOT "share/luajit-2.0.0-beta10/"
+ #define LUA_XPATH \
diff --git a/package/luajit/luajit-02-shared-lib.patch b/package/luajit/luajit-02-shared-lib.patch
new file mode 100644
index 0000000..d5122ba
--- /dev/null
+++ b/package/luajit/luajit-02-shared-lib.patch
@@ -0,0 +1,17 @@
+Compile the luajit binary dynamically against the luajit library
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+Index: b/src/Makefile
+===================================================================
+--- a/src/Makefile
++++ b/src/Makefile
+@@ -629,7 +629,7 @@
+ 
+ $(LUAJIT_T): $(TARGET_O) $(LUAJIT_O) $(TARGET_DEP)
+ 	$(E) "LINK      $@"
+-	$(Q)$(TARGET_LD) $(TARGET_ALDFLAGS) -o $@ $(LUAJIT_O) $(TARGET_O) $(TARGET_ALIBS)
++	$(Q)$(TARGET_LD) $(TARGET_ALDFLAGS) -o $@ $(LUAJIT_O) -lluajit -L. $(TARGET_ALIBS)
+ 	$(Q)$(TARGET_STRIP) $@
+ 	$(E) "OK        Successfully built LuaJIT"
+ 
diff --git a/package/luajit/luajit-03-dont-strip.patch b/package/luajit/luajit-03-dont-strip.patch
new file mode 100644
index 0000000..9651cdf
--- /dev/null
+++ b/package/luajit/luajit-03-dont-strip.patch
@@ -0,0 +1,23 @@
+Don't strip the library and binary
+
+This allows Buildroot to do it if needed, but only if needed.
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+Index: b/src/Makefile
+===================================================================
+--- a/src/Makefile
++++ b/src/Makefile
+@@ -625,12 +625,10 @@
+ $(LUAJIT_SO): $(LJVMCORE_O)
+ 	$(E) "DYNLINK   $@"
+ 	$(Q)$(TARGET_LD) $(TARGET_ASHLDFLAGS) -o $@ $(LJVMCORE_DYNO) $(TARGET_ALIBS)
+-	$(Q)$(TARGET_STRIP) $@
+ 
+ $(LUAJIT_T): $(TARGET_O) $(LUAJIT_O) $(TARGET_DEP)
+ 	$(E) "LINK      $@"
+ 	$(Q)$(TARGET_LD) $(TARGET_ALDFLAGS) -o $@ $(LUAJIT_O) -lluajit -L. $(TARGET_ALIBS)
+-	$(Q)$(TARGET_STRIP) $@
+ 	$(E) "OK        Successfully built LuaJIT"
+ 
+ ##############################################################################
diff --git a/package/luajit/luajit-04-no-bin-symlink.patch b/package/luajit/luajit-04-no-bin-symlink.patch
new file mode 100644
index 0000000..3eed7de
--- /dev/null
+++ b/package/luajit/luajit-04-no-bin-symlink.patch
@@ -0,0 +1,40 @@
+Do not use a symlink for the binary, simply name if luajit
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+Index: b/Makefile
+===================================================================
+--- a/Makefile
++++ b/Makefile
+@@ -41,8 +41,7 @@
+ INSTALL_MAN= $(INSTALL_SHARE)/man/man1
+ INSTALL_PKGCONFIG= $(INSTALL_LIB)/pkgconfig
+ 
+-INSTALL_TNAME= luajit-$(VERSION)
+-INSTALL_TSYMNAME= luajit
++INSTALL_TNAME= luajit
+ INSTALL_ANAME= libluajit-$(ABIVER).a
+ INSTALL_SONAME= libluajit-$(ABIVER).so.$(MAJVER).$(MINVER).$(RELVER)
+ INSTALL_SOSHORT= libluajit-$(ABIVER).so
+@@ -56,7 +55,6 @@
+ INSTALL_SHORT1= $(INSTALL_LIB)/$(INSTALL_SOSHORT)
+ INSTALL_SHORT2= $(INSTALL_LIB)/$(INSTALL_SOSHORT)
+ INSTALL_T= $(INSTALL_BIN)/$(INSTALL_TNAME)
+-INSTALL_TSYM= $(INSTALL_BIN)/$(INSTALL_TSYMNAME)
+ INSTALL_PC= $(INSTALL_PKGCONFIG)/$(INSTALL_PCNAME)
+ 
+ INSTALL_DIRS= $(INSTALL_BIN) $(INSTALL_LIB) $(INSTALL_INC) $(INSTALL_MAN) \
+@@ -114,13 +112,6 @@
+ 	  $(RM) $(FILE_PC).tmp
+ 	cd src && $(INSTALL_F) $(FILES_INC) $(INSTALL_INC)
+ 	cd lib && $(INSTALL_F) $(FILES_JITLIB) $(INSTALL_JITLIB)
+-	@echo "==== Successfully installed LuaJIT $(VERSION) to $(PREFIX) ===="
+-	@echo ""
+-	@echo "Note: the beta releases deliberately do NOT install a symlink for luajit"
+-	@echo "You can do this now by running this command (with sudo):"
+-	@echo ""
+-	@echo "  $(SYMLINK) $(INSTALL_TNAME) $(INSTALL_TSYM)"
+-	@echo ""
+ 
+ ##############################################################################
+ 
diff --git a/package/luajit/luajit.mk b/package/luajit/luajit.mk
new file mode 100644
index 0000000..84af2e6
--- /dev/null
+++ b/package/luajit/luajit.mk
@@ -0,0 +1,61 @@
+#############################################################
+#
+# luajit
+#
+#############################################################
+
+LUAJIT_VERSION = 2.0.0-beta10
+LUAJIT_SOURCE  = LuaJIT-$(LUAJIT_VERSION).tar.gz
+LUAJIT_SITE    = http://luajit.org/download
+
+LUAJIT_INSTALL_STAGING = YES
+
+define LUAJIT_NOLARGEFILE_FIX_MAKEFILE
+	$(SED) 's/TARGET_XCFLAGS= -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE/TARGET_XCFLAGS=/' $(@D)/src/Makefile
+endef
+
+ifneq ($(BR2_LARGEFILE),y)
+LUAJIT_POST_PATCH_HOOKS += LUAJIT_NOLARGEFILE_FIX_MAKEFILE
+endif
+
+# The luajit build procedure requires the host compiler to have the
+# same bitness as the target compiler. So when the target is a 32 bits
+# target, we pass -m32 to ensure that even on 64 bits hosts, a
+# compiler of the same bitness is used. However, this doesn't work for
+# x86 hosts targetting a x86_64 machine.
+ifeq ($(BR2_ARCH_IS_64),y)
+LUAJIT_HOST_CC=$(HOSTCC)
+else
+LUAJIT_HOST_CC=$(HOSTCC) -m32
+endif
+
+# We unfortunately can't use TARGET_CONFIGURE_OPTS, because the luajit
+# build system uses non conventional variable names.
+define LUAJIT_BUILD_CMDS
+	$(MAKE) PREFIX="/usr" \
+		STATIC_CC="$(TARGET_CC)" \
+		DYNAMIC_CC="$(TARGET_CC) -fPIC" \
+		TARGET_LD="$(TARGET_CC)" \
+		TARGET_AR="$(TARGET_AR) rcus" \
+		TARGET_STRIP="$(TARGET_STRIP)" \
+		CFLAGS="$(TARGET_CFLAGS)" \
+		LDFLAGS="$(TARGET_LDFLAGS)" \
+		HOST_CC="$(LUAJIT_HOST_CC)" \
+		HOST_CFLAGS="$(HOST_CFLAGS)" \
+		HOST_LDFLAGS="$(HOST_LDFLAGS)" \
+		-C $(@D) amalg
+endef
+
+define LUAJIT_INSTALL_STAGING_CMDS
+	$(MAKE) PREFIX="/usr" DESTDIR="$(STAGING_DIR)" -C $(@D) install
+endef
+
+define LUAJIT_INSTALL_TARGET_CMDS
+	$(MAKE) PREFIX="/usr" DESTDIR="$(TARGET_DIR)" -C $(@D) install
+endef
+
+define LUAJIT_CLEAN_CMDS
+	-$(MAKE) -C $(@D) clean
+endef
+
+$(eval $(generic-package))
-- 
1.7.9.5

[Buildroot] [PATCH 3/4] luajit: fix dependencies of Lua modules

[Francois Perrad]

BR2_PACKAGE_LUA_SHARED_LIBRARY is an internal of lua package

Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
---
 package/cgilua/Config.in        |    1 -
 package/copas/Config.in         |    1 -
 package/luafilesystem/Config.in |    1 -
 package/luasocket/Config.in     |    1 -
 package/rings/Config.in         |    1 -
 package/xavante/Config.in       |    1 -
 6 files changed, 6 deletions(-)

diff --git a/package/cgilua/Config.in b/package/cgilua/Config.in
index 2f9c452..01928f0 100644
--- a/package/cgilua/Config.in
+++ b/package/cgilua/Config.in
@@ -1,6 +1,5 @@
 config BR2_PACKAGE_CGILUA
 	bool "cgilua"
-	select BR2_PACKAGE_LUA_SHARED_LIBRARY
 	select BR2_PACKAGE_LUAFILESYSTEM
 	help
 	  CGILua is a tool for creating dynamic HTML pages
diff --git a/package/copas/Config.in b/package/copas/Config.in
index 36abcc1..9969c8f 100644
--- a/package/copas/Config.in
+++ b/package/copas/Config.in
@@ -2,7 +2,6 @@ config BR2_PACKAGE_COPAS
 	bool "copas"
 	select BR2_PACKAGE_COXPCALL
 	select BR2_PACKAGE_LUASOCKET
-	select BR2_PACKAGE_LUA_SHARED_LIBRARY # for luasocket
 	help
 	  Copas is a dispatcher based on coroutines that
 	  can be used by TCP/IP servers.
diff --git a/package/luafilesystem/Config.in b/package/luafilesystem/Config.in
index edcb414..7c130f8 100644
--- a/package/luafilesystem/Config.in
+++ b/package/luafilesystem/Config.in
@@ -1,6 +1,5 @@
 config BR2_PACKAGE_LUAFILESYSTEM
 	bool "luafilesystem"
-	select BR2_PACKAGE_LUA_SHARED_LIBRARY
 	help
 	  LuaFileSystem offers a portable way to access
 	  the underlying directory structure and file attributes.
diff --git a/package/luasocket/Config.in b/package/luasocket/Config.in
index 298db56..4526303 100644
--- a/package/luasocket/Config.in
+++ b/package/luasocket/Config.in
@@ -1,6 +1,5 @@
 config BR2_PACKAGE_LUASOCKET
 	bool "luasocket"
-	depends on BR2_PACKAGE_LUA_SHARED_LIBRARY
 	help
 	  LuaSocket is the most comprehensive networking support library
 	  for the Lua language.
diff --git a/package/rings/Config.in b/package/rings/Config.in
index 2fe14aa..d1f1efe 100644
--- a/package/rings/Config.in
+++ b/package/rings/Config.in
@@ -1,6 +1,5 @@
 config BR2_PACKAGE_RINGS
 	bool "rings"
-	depends on BR2_PACKAGE_LUA_SHARED_LIBRARY
 	help
 	  Provides a way to create new Lua states from within Lua.
 
diff --git a/package/xavante/Config.in b/package/xavante/Config.in
index a7df530..db34d66 100644
--- a/package/xavante/Config.in
+++ b/package/xavante/Config.in
@@ -1,6 +1,5 @@
 config BR2_PACKAGE_XAVANTE
 	bool "xavante"
-	select BR2_PACKAGE_LUA_SHARED_LIBRARY
 	select BR2_PACKAGE_CGILUA
 	select BR2_PACKAGE_COPAS
 	select BR2_PACKAGE_COXPCALL
-- 
1.7.9.5

[Buildroot] [PATCH 4/4] lua: refactor without sed

[Francois Perrad]

Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
---
 package/lua/lua.mk |   16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/package/lua/lua.mk b/package/lua/lua.mk
index 1e52075..8f71fc2 100644
--- a/package/lua/lua.mk
+++ b/package/lua/lua.mk
@@ -8,8 +8,9 @@ LUA_VERSION = 5.1.5
 LUA_SITE = http://www.lua.org/ftp
 LUA_INSTALL_STAGING = YES
 
+LUA_CFLAGS = -Wall
 ifeq ($(BR2_PACKAGE_LUA_SHARED_LIBRARY),y)
-	LUA_MYCFLAGS += -fPIC
+	LUA_CFLAGS += -fPIC
 endif
 
 LUA_MYLIBS += -ldl
@@ -17,28 +18,25 @@ LUA_MYLIBS += -ldl
 ifeq ($(BR2_PACKAGE_LUA_INTERPRETER_READLINE),y)
 	LUA_DEPENDENCIES = readline ncurses
 	LUA_MYLIBS += -lreadline -lhistory -lncurses
-	LUA_MYCFLAGS += -DLUA_USE_LINUX
+	LUA_CFLAGS += -DLUA_USE_LINUX
 else
-	LUA_MYCFLAGS += -DLUA_USE_POSIX -DLUA_USE_DLOPEN
+	LUA_CFLAGS += -DLUA_USE_POSIX -DLUA_USE_DLOPEN
 endif
 
-HOST_LUA_DEPENDENCIES =
-HOST_LUA_MYCFLAGS = -fPIC -DLUA_USE_DLOPEN -DLUA_USE_POSIX
+HOST_LUA_CFLAGS = -Wall -fPIC -DLUA_USE_DLOPEN -DLUA_USE_POSIX
 HOST_LUA_MYLIBS = -ldl
 
 define LUA_BUILD_CMDS
-	sed -i -e 's/-O2//' $(@D)/src/Makefile
 	$(MAKE) \
 	CC="$(TARGET_CC)" RANLIB="$(TARGET_RANLIB)" \
-	MYCFLAGS="$(TARGET_CFLAGS) $(LUA_MYCFLAGS)" \
+	CFLAGS="$(TARGET_CFLAGS) $(LUA_CFLAGS)" \
 	MYLIBS="$(LUA_MYLIBS)" AR="$(TARGET_CROSS)ar rcu" \
 	PKG_VERSION=$(LUA_VERSION) -C $(@D)/src all
 endef
 
 define HOST_LUA_BUILD_CMDS
-	sed -i -e 's/-O2//' $(@D)/src/Makefile
 	$(MAKE) \
-	MYCFLAGS="$(HOST_LUA_MYCFLAGS)" \
+	CFLAGS="$(HOST_LUA_CFLAGS)" \
 	MYLIBS="$(HOST_LUA_MYLIBS)" \
 	PKG_VERSION=$(LUA_VERSION) -C $(@D)/src all
 endef
-- 
1.7.9.5

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

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

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

[François Perrad]

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 at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mv_lua.pl
Type: application/octet-stream
Size: 1699 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120719/95aeccac/attachment.obj>

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

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [UNSURE]Re: [PATCH 1/4] add host arch detection and Kconfig BR2_HOSTARCH

[François Perrad]

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

[Buildroot] [UNSURE]Re: [PATCH 1/4] add host arch detection and Kconfig BR2_HOSTARCH

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [UNSURE]Re: [PATCH 1/4] add host arch detection and Kconfig BR2_HOSTARCH

[François Perrad]

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

[Buildroot] [UNSURE]Re: [PATCH 1/4] add host arch detection and Kconfig BR2_HOSTARCH

[Thomas Petazzoni]

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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com