lua-users home
lua-l archive

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


I've updated the Debian package to the latest -rc source and restored
the module paths to the "lua/5.1" form.  Attached is some new text in
the README regarding module paths.

--John
Module paths
------------
Upstream's package.path and package.cpath consist of paths under /usr/local.
Corresponding paths under /usr are required to support Lua modules which will
be packaged for Debian.  These have been added except in the case of /usr/lib
in package.path.  Debian policy is clear that architecture-independent files
(i.e. .lua modules) be placed under /usr/share, while binary files (i.e. module
.so's) be under /usr/lib.  This implies that Lua's package.path should not
contain references to /usr/lib.  Since /usr/local is not under Debian
management, upstream's original paths were left intact.

The implication for Lua modules packaged for Debian is that the correct module
paths must be used at install time.  Instead of hard coding these paths, use
of the "module_dir" and "binary_module_dir" info made available through
pkg-config is recommended.  For example, in a makefile:

  PREFIX = /usr
  MODULE_PATH = $(PREFIX)/$(shell pkg-config lua5.1 --variable=module_dir)
  BIN_MODULE_PATH = $(PREFIX)/$(shell pkg-config lua5.1 --variable=binary_module_dir)

For those concerned about either pkg-config or these variables not being
available everywhere, it is trivial to fall back to a hard coded path.

Another addition to upstream's module paths is the "liblua-?.so" variations in
package.cpath.  These allow binary modules following libtool naming convention
to be loaded without any noticeable difference to users of the module.  In
other words, module "foo" can be loaded with "require 'foo'" regardless of
whether the binary was named according to libtool convention or not.