This section describes the status of the Lua libraries in the ports tree and its integration with the ports system.
There are many versions of the Lua libraries and corresponding interpreters, which conflict between them (install files under the same name). In the ports tree this problem has been solved by installing each version under a different name using version number suffixes.
The obvious disadvantage of this is that each application has to be modified to find the expected version. But it can be solved by adding some additional flags to the compiler and linker.
Applications that use Lua
should normally build for just one version. However, loadable
modules for Lua are built in a separate flavor for each Lua
version that they support, and dependencies on such modules
should specify the flavor using the
@${LUA_FLAVOR}
suffix on the port
origin.
A port using Lua should have a line of this form:
USES= lua
If a specific version of Lua, or range of versions, is
needed, it can be specified as a parameter in the form
XY
(which may be used multiple times),
XY+
, -XY
, or
XY-ZA
. The default version of
Lua as set via
DEFAULT_VERSIONS
will be used if it falls
in the requested range, otherwise the closest requested
version to the default will be used. For example:
USES= lua:52-53
Note that no attempt is made to adjust the version selection based on the presence of any already-installed Lua version.
The XY+
form of version specification
should not be used without careful consideration; the
Lua API changes to some extent in
every version, and configuration tools like
CMake or
Autoconf will often fail to work
on future versions of Lua until
updated to do so.
Software that uses Lua may have been written to auto-detect the Lua version in use. In general ports should override this assumption, and force the use of the specific Lua version selected as described above. Depending on the software being ported, this might require any or all of:
Using LUA_VER
as part of a parameter
to the software's configuration script via
CONFIGURE_ARGS
or
CONFIGURE_ENV
(or equivalent for other
build systems);
Adding -I${LUA_INCDIR}
,
-L${LUA_LIBDIR}
, and
-llua-${LUA_VER}
to CFLAGS
,
LDFLAGS
, LIBS
respectively
as appropriate;
Patch the software's configuration or build files to select the correct version.
A port which installs a Lua
module (rather than an application that simply makes use of
Lua) should build a separate
flavor for each supported Lua
version. This is done by adding the module
parameter:
USES= lua:module
A version number or range of versions can be specified as well; use a comma to separate parameters.
Since each flavor must have a different package name, the
variable LUA_PKGNAMEPREFIX
is provided which
will be set to an appropriate value; the intended usage
is:
PKGNAMEPREFIX= ${LUA_PKGNAMEPREFIX}
Module ports should normally install files only to
LUA_MODLIBDIR
,
LUA_MODSHAREDIR
,
LUA_DOCSDIR
, and
LUA_EXAMPLESDIR
, all of which are set up
to refer to version-specific subdirectories. Installing any
other files must be done with care to avoid conflicts between
versions.
A port (other than a Lua module)
which wishes to build a separate package for each
Lua version should use the
flavors
parameter:
USES= lua:flavors
This operates the same way as the module
parameter described above, but without the assumption that the
package should be documented as a Lua
module (so LUA_DOCSDIR
and
LUA_EXAMPLESDIR
are not defined by
default). However, the port may choose to define
LUA_DOCSUBDIR
as a suitable subdirectory name
(usually the port's PORTNAME
as long as this
does not conflict with the PORTNAME
of any
module), in which case the framework will define both
LUA_DOCSDIR
and
LUA_EXAMPLESDIR
.
As with module ports, a flavored port should avoid installing
files that would conflict between versions. Typically this is done
by adding LUA_VER_STR
as a suffix to program
names (e.g. using
USES=uniquefiles), and
otherwise using either LUA_VER
or
LUA_VER_STR
as part of any other files or
subdirectories used outside of LUA_MODLIBDIR
and LUA_MODSHAREDIR
.
These variables are available in the port.
Name | Description |
---|---|
LUA_VER | The Lua version that
is going to be used (for example,
5.1 ) |
LUA_VER_STR | The Lua version
without the dots (for example,
51 ) |
LUA_FLAVOR | The flavor name corresponding to the selected Lua version, to be used for specifying dependencies |
LUA_BASE | The prefix that should be used to locate Lua (and components) that are already installed |
LUA_PREFIX | The prefix where Lua (and components) are to be installed by this port |
LUA_INCDIR | The directory where Lua header files are installed |
LUA_LIBDIR | The directory where Lua libraries are installed |
LUA_REFMODLIBDIR | The directory where
Lua module libraries
(.so ) that are already
installed are to be found |
LUA_REFMODSHAREDIR | The directory where
Lua modules
(.lua ) that are already
installed are to be found |
LUA_MODLIBDIR | The directory where
Lua module libraries
(.so ) are to be installed
by this port |
LUA_MODSHAREDIR | The directory where
Lua modules
(.lua ) are to be installed
by this port |
LUA_PKGNAMEPREFIX | The package name prefix used by Lua modules |
LUA_CMD | The name of the Lua
interpreter (e.g. lua53 ) |
LUAC_CMD | The name of the Lua
compiler (e.g. luac53 ) |
These additional variables are available for ports that
specified the module
parameter:
Name | Description |
---|---|
LUA_DOCSDIR | the directory to which the module's documentation should be installed. |
LUA_EXAMPLESDIR | the directory to which the module's example files should be installed. |
This example shows how to reference a Lua module required at run time. Notice that the reference must specify a flavor.
PORTNAME= sample DISTVERSION= 1.2.3 CATEGORIES= whatever MAINTAINER= john@doe.tld COMMENT= Sample RUN_DEPENDS= ${LUA_REFMODLIBDIR}/lpeg.so:devel/lua-lpeg@${LUA_FLAVOR} USES= lua .include <bsd.port.mk>
PORTNAME= sample DISTVERSION= 1.2.3 CATEGORIES= whatever PKGNAMEPREFIX= ${LUA_PKGNAMEPREFIX} MAINTAINER= john@doe.tld COMMENT= Sample USES= lua:module DOCSDIR= ${LUA_DOCSDIR} .include <bsd.port.mk>
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.