Liblua redux

[orlitzky]

The first commit here fixes the issue #111 that I reported recently. The second... well, someone has to do something about that mess.

Fortunately, it's all obsolete. Debian has pkg-config files now (albeit with nonstandard names), and even modulo that, it's better to pass -I, -l, and -L flags to the build system than it is to pass --with-lua=<path> and have the configure script reinvent the wheel. The new stuff is only lightly tested, but I'll soon add it to our Gentoo package to fix the lua-5.1 detection issue. The design is sound even if I've overlooked a detail or two. I'm happy to fix bugs down the road if people run into problems.

A few scenarios are described in the commit message, but I expect almost everyone to be covered by pkg-config out of the box.

[mkszuba]

In addition to the Debian case you might also want to handle the FreeBSD one, where the relevant pkgconfig modules are called "lua-5.x" with a hyphen. I've also seen the form "lua5x" but since I have yet to see any packages whose build scripts actually consider that one, supporting it here is probably not worth the effort.

[orlitzky]

I would really like to discourage the idea that a good way to package software is to have every program on earth guess at every wrong way that every library on earth could possibly be installed. Debian was specifically supported by the old code, probably because the maintainers used Debian. I've kept that compatibility. On FreeBSD, it has likely never worked.

The upstream library name is "lua". If you change that, you have broken its API in the most egregious way possible. Likewise, the pkg-config module is named "lua". If you change it to anything else, well... what do you think is going to happen? You've prevented pkg-config from doing its only job; from locating the package's information based on a standard name (lua.pc).

It looks like things worked OK on FreeBSD up until 5.1, where they changed the layout to the same one you've adopted in Gentoo. We'll be fine because eselect-lua creates symlinks with the correct names, but if FreeBSD doesn't do that, you'll have to follow their instructions and either pass LIBS="-llua-${LUA_VER}" on the command-line, or patch the build system yourself. (This is not a change in behavior.)

[orlitzky]

Note that this is still wrong on Gentoo, because the currently-eselected version of Lua will always be used, even if that's not the version you want. To make it work correctly, the AC_SEARCH_LIBS detection should come first, with the user expected to override the include/library directories with the desired ones. This is so far impossible on Gentoo (and Debian, and FreeBSD...), however, which is what my thread is about on gentoo-dev =)

[orlitzky]

I just send another long email about it. In my last comment, I said "To make it work correctly, the AC_SEARCH_LIBS detection should come first," which is not quite true. This PR is fine as-is. What should be possible is to override the PKG_CONFIG_PATH on Gentoo so that it finds lua.pc at e.g. /usr/lib64/pkgconfig/lua5.2/lua.pc. Then there's no need to pass -I and -L flags to override the default system lua.