Re: lua.pc pkg-config file

[William Ahern <william@...>]

On Wed, Mar 25, 2015 at 02:35:07PM +0100, Nicola Fontana wrote:
> Il Wed, 25 Mar 2015 14:01:58 +0100 Enrico Tassi <gares@fettunta.org> scrisse:
> 
> > The best way out is that the Lua authors fix the spelling, exactly as
> > they fixed it for the language name (not LUA, but Lua).
> 
> I second that. I personally used a variation of this code (courtesy of
> AX_LUA [1]):
> 
> dnl Some default directories to search.
> LUA_SHORT_VERSION=`echo "$LUA_VERSION" | $SED 's|\.||'`
> m4_define_default([_AX_LUA_INCLUDE_LIST],
> [ /usr/include/lua$LUA_VERSION \
> /usr/include/lua-$LUA_VERSION \
> /usr/include/lua/$LUA_VERSION \
> /usr/include/lua$LUA_SHORT_VERSION \
> /usr/local/include/lua$LUA_VERSION \
> /usr/local/include/lua-$LUA_VERSION \
> /usr/local/include/lua/$LUA_VERSION \
> /usr/local/include/lua$LUA_SHORT_VERSION \
> ])
> 
> and I bet there are much more snippets around following this pattern.

Unfortunately that only handles the easy cases, which are already handled by
pkg-config. But for things like firmwares and other ad hoc installations,
/usr/local is meaningless. Also, none of the above will find the LuaJIT
headers, which are identical to PUC Lua headers from an API perspective.

One of the strategies I use in my luapath script (which automates all of
this using POSIX-portable shell code) is to first locate the appropriate lua
binary in $PATH, using whatever scheme you use to detect the version. If the
lua binary path is LUA, then look for ${LUA}/../include/lua.h and
${LUA}/../include/*/lua.h, and examine them for the correct LUA_VERSION_NUM.
For example, using the POSIX-specied -E flag

  printf "#include <lua.h>\n@@LUA_VERSION_NUM@@\n" \
  | cc -E - -I/include/path/to/test \
  | sed -ne 's/@@\([[:digit:]]*\)@@/\1/p

you can check if LUA_VERSION_NUM exists and what it expands to.

Another strategy I use in luapath is to do `pkg-config --list-all`, grep for
anything that looks like a lua package (including luajit), and then
iteratively test each package name to see if `pkg-config --cflags $NAME`
locates the correct header location.

AX_LUA is nice except that you can only build against a single version of
Lua at a time. If you support multiple Lua versions as a module author, it
becomes _very_ tedious to have to `./configure && make` once for each
version just to make sure your code still compiles after each edit. (And if
you don't check after each edit, it quickly becomes a headache to support
multiple Lua versions, which is why projects which consistently work across
Lua 5.1, 5.2, and 5.3 are so rare.)

> An upstream pkg-config that imposes a specific versioning scheme would
> resolve this issue.
> 

It sucks that people are relying on pkg-config so much. If pkg-config is
installed, then you're already on Linux or one of the BSDs (and OS X only
_if_ something like homebrew is already installed), in which case
portability is relatively simple. I just had to hack the OpenDKIM build
because it assumes pkg.m4 already exists, which is only installed with
pkg-config.

pkg-config is useful when it's available. But it's _not_ available in
environments where autotools actually adds value. Why bother using autoconf
and automake, which go to extreme lengths to ship the necessary build
dependencies, and which add tremendous complexity, then have a hard
dependency on something like pkg-config, which would only be available by
default on systems where you wouldn't even need automake to begin with.