[RFC PATCH 0/3] Simplify build system to allow building against LuaJIT

[Jordan Yelloz]

Hi,

I am interested in getting swupdate to get its Lua support from LuaJIT. I'm not
doing this for performance reasons or anything, but to avoid including multiple
versions of Lua on an embedded system since another package on the system
requires LuaJIT.

Anyway, most of the problems in achieving this task are caused by the
limitations in the swupdate build system which I have been able to fix.

I've put together a small patch that simplifies the way swupdate links against
Lua (and potentially other packages that use pkg-config in the future) so that
it only needs the pkg-config package name to get the correct compiler/linker
flags for a specified package.

First, I changed the CONFIG_LUAVERSION to CONFIG_LUAPKG since we don't care
about the version anymore but we care about the pkg-config package name of the
Lua implementation. This change will require people to update their defconfigs
if they've set a custom Lua version in the past. Hopefully this won't be too
much of a problem.

Next, I've added a new step to pkg_check_modules that provides the libraries
returned by pkg-config in the format that swupdate's LDLIBS expects.

Finally, I've updated the Lua section of Makefile.flags so it can make use of
the new configuration value and pkg_check_modules variable.

Obviously, with a Lua API less than 5.2, custom handlers cannot be used but the
other 2 use cases work fine and if we add some lua-compat-5.3
<https://github.com/keplerproject/lua-compat-5.3/tree/master/c-api> files to
the swupdate build we can even get custom handlers to work with Lua 5.1
implementations as well but that's for a future patch set.

--
Jordan


Jordan Yelloz (3):
Kconfig: removed LUAVERSION, added LUAPKG
Makefile.flags: added $(PKG)_LDLIBS to pkg_check_modules
Makefile.flags: simplified Lua build support.

Kconfig | 10 ++++------
Makefile.flags | 5 +++--
2 files changed, 7 insertions(+), 8 deletions(-)

--
2.9.3

[Jordan Yelloz]

This allows for a configuration value that directly ties the Lua
implementation to a pkg-config package.

Signed-off-by: Jordan Yelloz <jor...@yelloz.me>
---
Kconfig | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/Kconfig b/Kconfig
index cfd10b24de68..36831a494f28 100644
--- a/Kconfig
+++ b/Kconfig
@@ -130,14 +130,12 @@ config LUA
comment "Lua support needs a Lua interpreter"
depends on !HAVE_LUA

-config LUAVERSION
- string "LUA version"
- default ""
+config LUAPKG
+ string "LUA pkg-config name"
+ default "lua"
depends on LUA
help
- Allow to specify which version must be taken. This is useful
- in case of multiple versions of the LUA interpreter in the system.
-
+ Which pkg-config package supplies the Lua API.

# These are auto-selected by other options

--
2.9.3

[Jordan Yelloz]

Now the Lua compiler and linker flags are sourced directly from
pkg-config. There's no longer any hard-coded libraries or dependency on
library name/pkg-config name patterns.

Signed-off-by: Jordan Yelloz <jor...@yelloz.me>
---

Makefile.flags | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile.flags b/Makefile.flags
index bab1e3a8bfe7..9f6f3026440c 100644
--- a/Makefile.flags
+++ b/Makefile.flags
@@ -94,11 +94,11 @@ endif
LDLIBS += pthread
# lua
ifneq ($(CONFIG_LUA),)
-LDLIBS += lua${CONFIG_LUAVERSION} dl m
LDFLAGS_swupdate += -Wl,-E
-$(eval $(call pkg_check_modules, LUABUILD, lua${CONFIG_LUAVERSION}))
+$(eval $(call pkg_check_modules, LUABUILD, ${CONFIG_LUAPKG}))
KBUILD_CFLAGS += $(LUABUILD_CFLAGS)
KBUILD_LIBS += $(LUABUILD_LIBS)
+LDLIBS += $(LUABUILD_LDLIBS)
endif


--
2.9.3

[Jordan Yelloz]

This allows LDLIBS to be dynamically supplied with library values
directly from pkg-config.

Signed-off-by: Jordan Yelloz <jor...@yelloz.me>
---

Makefile.flags | 1 +
1 file changed, 1 insertion(+)

diff --git a/Makefile.flags b/Makefile.flags
index b1c9e9876b5f..bab1e3a8bfe7 100644
--- a/Makefile.flags
+++ b/Makefile.flags
@@ -70,6 +70,7 @@ endif
define pkg_check_modules
$(1)_CFLAGS := $(shell $(PKG_CONFIG) $(PKG_CONFIG_FLAGS) --cflags $(2))
$(1)_LIBS := $(shell $(PKG_CONFIG) $(PKG_CONFIG_FLAGS) --libs $(2))
+$(1)_LDLIBS := $(patsubst -l%,%,$(shell $(PKG_CONFIG) $(PKG_CONFIG_FLAGS) --libs-only-l $(2)))
endef

ifeq ($(CONFIG_STATIC),y)
--
2.9.3

[Stefano Babic]

Hi Jordan,

On 28/08/2016 00:44, Jordan Yelloz wrote:
> Hi,
>
> I am interested in getting swupdate to get its Lua support from LuaJIT. I'm not
> doing this for performance reasons or anything, but to avoid including multiple
> versions of Lua on an embedded system since another package on the system
> requires LuaJIT.
>
> Anyway, most of the problems in achieving this task are caused by the
> limitations in the swupdate build system which I have been able to fix.
>
> I've put together a small patch that simplifies the way swupdate links against
> Lua (and potentially other packages that use pkg-config in the future) so that
> it only needs the pkg-config package name to get the correct compiler/linker
> flags for a specified package.
>
> First, I changed the CONFIG_LUAVERSION to CONFIG_LUAPKG since we don't care
> about the version anymore but we care about the pkg-config package name of the
> Lua implementation. This change will require people to update their defconfigs
> if they've set a custom Lua version in the past. Hopefully this won't be too
> much of a problem.

I hope thi, too. Reason of this strange setup for LUA was a project
having multiple versions of LUA in the system (some legacy packets
required an older version).

I agree this is an exception in the build and should be fixed.

>
> Next, I've added a new step to pkg_check_modules that provides the libraries
> returned by pkg-config in the format that swupdate's LDLIBS expects.
>
> Finally, I've updated the Lua section of Makefile.flags so it can make use of
> the new configuration value and pkg_check_modules variable.
>
> Obviously, with a Lua API less than 5.2, custom handlers cannot be used but the
> other 2 use cases work fine and if we add some lua-compat-5.3
> <https://github.com/keplerproject/lua-compat-5.3/tree/master/c-api> files to
> the swupdate build we can even get custom handlers to work with Lua 5.1
> implementations as well but that's for a future patch set.

Indeed. We are working for next releases.

Any reasons why you marked your patches with the RFC tags ? I do not see
any particular reason why I should not merge them. Or do you plan an
improved version ?


Best regards,
Stefano Babic

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Jordan Yelloz]

On 08/28/2016 10:35 AM, Stefano Babic wrote:

> Any reasons why you marked your patches with the RFC tags ? I do not see
> any particular reason why I should not merge them. Or do you plan an
> improved version ?

I just wanted to see if anyone disapproved of my changing the
CONFIG_LUAVERSION value and if anybody else has started working on
improving Lua support in the build system. If you think my patch set is
good enough then I agree that it should be applied to master.

--
Jordan

[Stefano Babic]

Hi Jordan,

Nice. I will just wait a couple of days to check if there will be some
comments - if none, I will apply your patchset.

Best regards,
Stefano

[Jörg Krause]

Hi,

On Monday, August 29, 2016 at 9:09:26 AM UTC+2, Stefano Babic wrote:

Hi Jordan,

On 28/08/2016 22:52, Jordan Yelloz wrote:
> On 08/28/2016 10:35 AM, Stefano Babic wrote:
>
>> Any reasons why you marked your patches with the RFC tags ? I do not see
>> any particular reason why I should not merge them. Or do you plan an
>> improved version ?
>
> I just wanted to see if anyone disapproved of my changing the
> CONFIG_LUAVERSION value and if anybody else has started working on
> improving Lua support in the build system. If you think my patch set is
> good enough then I agree that it should be applied to master.
>

Nice. I will just wait a couple of days to check if there will be some
comments - if none, I will apply your patchset.

I  would like to check this on Buildroot in a couple of days.

Best regards

Jörg Krause

[Stefano Babic]

Hi Jörg,

Have you checked the patches or do you prefer I merge them before you test ?

Best regards,
Stefano Babic

[Jörg Krause]

Hi Stefano,

Somehow, I do not receive these mails on my mail account, but only on
my Google account and Google does not forwared the messages :-(

Yes, please merge the patches so I can fetch them from git.

Best regards
Jörg Krause

[Stefano Babic]

On 28/08/2016 00:44, Jordan Yelloz wrote:

Applied to master, thanks !

[Jörg Krause]

Hi,

I've tested your patches with Buildroot against Lua 5.1/5.2/5.3 and LuaJIT 2.0.

As you mentioned, it is not possible to build SWupdate with Lua 5.1 or LuaJIT when CONFIG_HANDLER_IN_LUA is set, but unsetting the Lua handlers works. However, this is not related to your patches. No problems, if CONFIG_HANDLER_IN_LUA is unset, the necessary libraries are found and probably linked.

Lua 5.2 and Lua 5.3 works as expected with CONFIG_HANDLER_IN_LUA set.