Re: [ANN] Lua 5.1 Debian package

[John Belmonte <john@...>]

Mike Pall wrote:
> Maybe a compromise could be reached by requiring Debian
> originated modules to install an additional symlink:
>   foo.so -> liblua-foo.so
> This way the modification of package.cpath can be avoided, too.
> The install target in the example needs to be extended like this:
>   cd $(RPATH); ln -sf liblua-foo.so foo.so
> 
> Module authors could then be given a standard Makefile template
> which has a default target (build 'by hand', i.e. gcc -shared)
> and a libtool target. The former is useful for systems without
> GNU toolchains because it can be easily understood and modified.
> A C module can be installed with both methods and can be run by
> both standard Lua and Debian Lua. IMHO this is an important
> property.

I think it would be best to separate the use of the "lib" prefix naming
convention from whether libtool is used or not.  If you take a generic
approach to creating a Lua library/module, you'll find that you can't
assume whether users will link it to their app statically or load it via
require (they might even link to it dynamically via the link line rather
than require).  In the static case, clearly "foo.a" isn't going to work
too well because you can't use "-lfoo" on the link line, and since it
will pollute the /usr/lib namespace if "lua" doesn't appear in the name.
 So if you buy that the static library should start with lib and have
"lua" in the name somewhere, and that the .a and .so should be named
consistently to each other, and resolve the constraints of the Lua
dynamic loading system, the logical result is "liblua-foo.{a,so}".

--John