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

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Fri Jul 20 18:41:46 UTC 2012


Le Fri, 20 Jul 2012 20:24:27 +0200,
François Perrad <francois.perrad at 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


More information about the buildroot mailing list