Re: Lua on FreeBSD

[William Ahern <william@...>]

On Fri, Feb 27, 2015 at 10:45:02PM +0100, Lev wrote:
> I'm trying to port my Linux application to FreeBSD.
> 
> I found that lua doesn't supply lua52.pc on FreeBSD. Is this intentional? Or
> shall I say that the FreeBSD guys doesn't pack lua52.pc in FreeBSD?

The package name and the pkg-config name are different.

$ pkg info | grep lua\*5\*2 | cut -d' ' -f1
lua52-5.2.3_4

$ find /usr/local -name lua\*5\*2.pc
/usr/local/libdata/pkgconfig/lua-5.2.pc

$ pkg-config --cflags lua-5.2
-I/usr/local/include/lua52  

> What is your recommendation for a build system for an application that is
> using Lua, and the aim is to make it portable across Linux and *BSD?

All of my projects build out-of-the-box on Linux, *BSD, and Solaris. And all
but one also build out-of-the-box on AIX:

	http://25thandClement.com/~william/projects/cqueues.html
	http://25thandClement.com/~william/projects/lunix.html
	http://25thandClement.com/~william/projects/luaossp.html

However, I require GNU Make, which let's me call the shell and conditionally
set various variables (if the builder didn't already set them). I'm moving
to autoconf for some of them, but not automake or libtool. My Makefiles are
a little difficult to follow because they're non-recursive, and plug into a
larger non-recursive build framework at work. If they weren't non-recursive
it would be easier. You can also look at the PUC Lua makefiles for
inspiration.

All of my projects can also concurrently build Lua 5.1, 5.2, and 5.3
modules. This is a big headache for most Lua packages because at best they
require 3 separate invocations; at worst they just get hopelessly confused.

I've written a POSIX-portable shell script, luapath, which helps me
automatically locate the correct headers for each version at compile-time.

	http://25thandclement.com/~william/projects/luapath.html

It can introspect the system using different hueristics (all optional).
pkg-config is only one option (-k). It can also inspect CPPFLAGS, so that
the builder can explicitly specify all the Lua header paths in one go, like

	make CPPFLAGS="-I/usr/local/lua51/include \
	-I/usr/local/lua52/include -I/usr/local/lua53/include"

For example, if CPPFLAGS is set as above, then on my OS X desktop

	CPPFLAGS="$(CPPFLAGS)" luapath -v5.2 -krxm3 cppflags

will emit

	-I/usr/local/lua52/include

And you can use it in your build rule like

	5.2/foo.so: foo.c
		test "5.2" = "$$(CPPFLAGS='$(CPPFLAGS)' luapath -v5.2 -krxm3 version)"
		mkdir -p $(@D)
		$(CC) $(CFLAGS) \
		"$$(CPPFLAGS='$(CPPFLAGS)' luapath -v5.2 -krxm3 version)" \
		$(CPPFLAGS) -o $@ $^ $(SOFLAGS) $(LDFLAGS) $(LIBS)

You need to arrange for CFLAGS and SOFLAGS to contain the proper compiler
flags. Rather than duplicate the rule three times, for GNU and BSD Make
you can do something like:

	%/foo.so: foo.c
		test "$(@D)" = "$$(CPPFLAGS='$(CPPFLAGS)' luapath -v$(@D) -krxm3 version)"
		mkdir -p $(@D)
		$(CC) $(CFLAGS) \
		"$$(CPPFLAGS='$(CPPFLAGS)' luapath -v$(@D) -krxm3 version)" \
		$(CPPFLAGS) -o $@ $^ $(SOFLAGS) $(LDFLAGS) $(LIBS)

where $(@D) evaluates to 5.1, 5.2, or 5.3. Although the rule isn't strictly
POSIX.

I would suggest not using libtool as the combination of supporting different
Lua versions, plus the fact that by convention Lua modules should not
explicitly link against the Lua VM library, will cause you to run into many
headaches. Plus unless you're using automake then invoking libtool with the
right options can be difficult. libtool really isn't necessary for modern
systems, especially for something as simple as Lua modules where you're not
worried about any kind of specialized linker versioning.