lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Luiz wrote:
>>While doing this packaging work I've come to appreciate libtool, and I
>>have to say I think it's not given the attention it deserves in the
>>list's discussions on both building Lua itself and building Lua apps and
>>binary modules.
> We certainly do not want to rely on libtool for building Lua. Moreover,
> we do not encourage building Lua (the library) as a .so... We do
> encourage building lua (the interpreter) statically and exporting the
> Lua API so that dynamic libs work fine with it.

Sorry for the misunderstanding, I wasn't suggesting that the Lua build
rely solely on libtool.  It may be worth considering as a make target
given the coverage it offers.

You cleared up your position on the Lua library as an .so in another
posting, but I thought I should note the importance of .so's in the
workings of a Unix distribution.   Unless libraries are dynamically
linked, when a serious bug or security issue in a library comes up,
every package relying on it (perhaps hundreds) must be rebuilt for every
target architecture (12 in the case of Debian) and redistributed to
users.  That wouldn't scale too well.

>>I could probably make a similar argument for the pkg-config tool.
> Lua 5.1 does include etc/lua,pc. Feedback on this is appreciated.

Please consider the following addition to lua.pc so that software
installing Lua modules has an alternative to hard coding the module paths.

  # Install paths for Lua modules, relative to the install root.  For
  # example, if a package wants to install Lua source modules to the
  # /usr/local tree, it should use this path:
  #    /usr/local/`pkg-config lua --variable=module_dir`