NAME
port-modules
—
documentation and conventions used in
port modules
DESCRIPTION
The OpenBSD Ports framework is based on a gigantic makefile named bsd.port.mk(5).
In order to curb unwieldy growth, parts of the framework that are
not always needed have been set apart in optional files called
port modules
, which are retrieved as needed through
the MODULES
variable of
bsd.port.mk(5).
Some of these modules correspond to basic mechanisms which are not always needed, such as GNU autoconf, or perl5.
For convenience, setting CONFIGURE_STYLE
in a port's main Makefile is enough to get perl5 or autoconf support, but
gnu, imake and
perl5 are actually modules, and there is some glue in
bsd.port.mk(5) that magically adds the required module in
that case. This doesn't work when parsing modules. For instance, if you set
CONFIGURE_STYLE=gnu
in a module, you also need to
MODULES += gnu
.
Other modules correspond to shortcuts for using some other ports as dependencies without needing to hardcode too much, such as the qt ports.
THE MODULES LOOK-UP MECHANISM
The variable MODULES
should contain a list
of module names. Some core modules are a single word, all other modules
should be ${PKGPATH}. If the module is
some/dir/portname, the ports framework will look for
a file named
${PORTSDIR}/some/dir/portname/portname.port.mk and
include it.
Most modules should conform to this syntax. The historic practice of having a redirection file directly under ${PORTSDIR}/infrastructure/mk is deprecated for new modules.
Modules may refer to each other. The modules mechanism has
specific recursion handling such that adding MODULES +=
foo/bar
to a module will work as expected.
NAMING CONVENTIONS
Since there is no actual scope in makefiles, everything defined within a module will be global to the ports framework, and thus may interfere with other ports.
As far as possible, all variables and targets belonging to a
module named some/dir/foo should be named
MODFOO_*
and modfoo_*.
Following the same conventions as
bsd.port.mk(5), internal variables and targets not intended
for user consumption should be named _MODFOO_*
and
_modfoo_*.
For instance, if a module wants some value to be available for the
rest of the world, it should define MODFOO_VARNAME
,
with a name matching the basic infrastructure as far as possible. That is, a
port that defines specific dependencies will usually define
MODFOO_WANTLIB
,
MODFOO_LIB_DEPENDS
, and
MODFOO_RUN_DEPENDS
, as appropriate.
As an exception to the naming mechanism, some ports have several
distinct versions in the ports tree, say x11/qt3 and
x11/qt4. Instead of using the namespace
MODQT3*
, variables will usually drop the version
suffix and be simply called MODQT_*
so that a port
using the module can be switched from version to version without needing to
change everything.
It is highly desirable to define names in both namespaces for such
ports, for example to define both MODQT3_LIB_DEPENDS
and MODQT_LIB_DEPENDS
. Normal client ports will use
MODQT_LIB_DEPENDS
, but a port may exceptionally
import both modules with MODULES += x11/qt3 x11/qt4
and differentiate between qt3 and qt4 needs with
MODQT3_LIB_DEPENDS
and
MODQT4_LIB_DEPENDS
. See
print/poppler for an example.
OVERRIDING TARGET BEHAVIOR
The main framework contains several hooks that allow ports to override normal behavior. This evolved as an ad-hoc framework, where only hooks that turned out to be needed were added. If several modules define the same hook, hook behaviors will be invoked in sequence.
extract
- There is a
post-extract
hook that can be activated by definingMODFOO_post-extract
. It will be run right afterpost-extract
. patch
- There is a
post-patch
hook that can be activated by definingMODFOO_post-patch
. It will be run right afterpost-patch
and beforeREORDER_DEPENDENCIES
touches things. configure
- There is a
pre-configure
hook that can be activated by definingMODFOO_pre-configure
. It will be run right afterpre-configure
. The normaldo-configure
behavior is to invoke allMODFOO_configure
contents that are defined inCONFIGURE_STYLE
. By default,configure
will do nothing.Some
CONFIGURE_STYLE
values, namely perl, gnu, imake, automake, autoconf, and autoupdate will automatically import the correct module. User-defined modules must both add toCONFIGURE_STYLE
and import the correct module to override behavior.Contrary to other hooks, module behavior is not invoked in addition to
do-configure
, but as the normal configure process. Ifdo-configure
is overridden, normal hook processing will not happen. fake
- There is a
pre-fake
hook that can be activated by definingMODFOO_pre-fake
. This will be invoked right after mtree(8), and before the normalpre-fake
behavior.This can occasionally be used for ports that require some specific fake installation setup that will be provided by runtime dependencies.
install
- There is a
post-install
hook that can be activated by definingMODFOO_post-install
. This will be invoked at the end ofinstall
, right after the normalpost-install
behavior.
Some targets, such as do-build
or
do-install
, can't be overridden simply. A module
that, for instance, requires specific do-build
behavior should do so in two steps:
- Define a variable named
MODFOO_BUILD_TARGET
that contains the commands necessary fordo-build
:MODFOO_BUILD_TARGET = cmd1; cmd2
- Override
do-build
only if it's not already defined by the port proper:.if !target(do-build) do-build: @${MODFOO_BUILD_TARGET} .endif
do-build: @${MODBAR_BUILD_TARGET} @${MODFOO_BUILD_TARGET} ...
OVERRIDING VARIABLE BEHAVIOR
Some variables can be overridden by modules. Be very cautious, as this can make the module difficult to use, or interact badly with other modules. As a rule, always provide the override as:
VARIABLE ?= value
and provide a module-specific variable with the same value:
MODFOO_VARIABLE = value
The following variables can be overridden in a relatively safe
fashion: ALL_TARGET
,
CONFIGURE_SCRIPT
,
DESTDIRNAME
, DIST_SUBDIR
,
DISTNAME
, DISTFILES
,
EXTRACT_SUFX
, FAKE_FLAGS
,
FETCH_MANUALLY
, HOMEPAGE
,
IGNORE
, IS_INTERACTIVE
,
LIBTOOL_FLAGS
, MAKE_FILE
,
MASTER_SITES
,
MULTI_PACKAGES
, NO_BUILD
,
NO_TEST
, PATCH_LIST
,
PKG_ARCH
, PKGNAME*
,
PREFIX
, TEST_TARGET
,
TEST_IS_INTERACTIVE
,
REORDER_DEPENDENCIES
,
SEPARATE_BUILD
, USE_GMAKE
,
USE_LIBTOOL
.
The following variables can be added to in a relatively safe
fashion: BUILD_DEPENDS
,
CATEGORIES
, CONFIGURE_ARGS
,
CONFIGURE_ENV
, ERRORS
,
FAKE_FLAGS
, FLAVOR
,
FLAVORS
, INSTALL_TARGET
,
LIB_DEPENDS
, MAKE_ENV
,
MAKE_FLAGS
, PKG_ARGS
,
PSEUDO_FLAVORS
,
TEST_DEPENDS
,
REORDER_DEPENDENCIES
,
RUN_DEPENDS
, SUBST_VARS
,
WANTLIB
.
SPECIFIC MODULE INTERACTIONS
Some modules correspond to extra ports that will be used mostly as
BUILD_DEPENDS
or
RUN_DEPENDS
. Such modules can safely append values
directly to the BUILD_DEPENDS
,
RUN_DEPENDS
, LIB_DEPENDS
,
and WANTLIB
variables, as long as they also define
module-specific variables for all runtime dependencies.
Simple client ports will use the module directly, and thus inherit extra build and runtime dependencies.
More sophisticated ports can use
MULTI_PACKAGES
to select specific behavior:
build-time dependencies will always be needed. Runtime dependencies will be
selected on a subpackage basis, since runtime dependencies such as
LIB_DEPENDS-sub
do not inherit the default
LIB_DEPENDS
value. The client port's author must
only bear in mind that external modules may add values to the default
WANTLIB
, LIB_DEPENDS
, and
RUN_DEPENDS
, and thus that it is not safe to inherit
from it blindly.
Modules are imported during
.include
<bsd.port.mk>
Thus they can be affected by user choices such as setting a
variable to Yes or No. Modules may make decisions based on documented
MODFOO_BEHAVIOR
values.
When modules are processed, only a few
bsd.port.mk(5) variables are already defined. Modules may
depend upon the following variables already having a sane value:
DISTDIR
, LOCALBASE
,
NO_DEPENDS
, PKGPATH
,
PORTSDIR
, X11BASE
and all
arch-dependent constants from
bsd.port.arch.mk(5), such as
PROPERTIES
or LP64_ARCHS
.
Note that this is only relevant for tests. It is perfectly okay to define
variables or targets that depend on the basic ports framework without having
to care whether that variable is already defined, since
make(1) performs lazy evaluation.
CORE MODULES DOCUMENTATION
The following modules are available.
- apache-module
- cpan
- For perl ports coming from CPAN. Wrapper around the normal perl module
that fetches the file from the correct location depending on
DISTNAME
, and sets a defaultPKGNAME
. Also affectsTEST_DEPENDS
,CONFIGURE_STYLE
,PKG_ARCH
, andCATEGORIES
.Some CPAN modules are only indexed by author, set
CPAN_AUTHOR=ID
to locate the right directory.If no
HOMEPAGE
is defined, it will default to http://search.cpan.org/dist/${DISTNAME:C/-[^-]*$//}/User settings: set
CPAN_REPORT
to Yes,CPAN_REPORT_DB
to a valid directory, andCPAN_REPORT_FROM
to a valid email address to automate the reporting of regression tests to CPAN.If
MODCPAN_EXAMPLES
is set, the following variables will be set.MODCPAN_EXAMPLES_DIST
will hold the default directory in the distfile with example scripts.MODCPAN_EXAMPLES_DIR
will be set to the standard installation directory for examples. Sets thepost-install
target if none has been defined to install the examples, otherwiseMODCPAN_POST_INSTALL
should be used as such:post-install: ... ${MODCPAN_POST_INSTALL}
- databases/mariadb
- Adds small framework for testing ports that require running MariaDB.
Defines
MODMARIADB_TEST_TARGET
which consists actual commands to run indo-test
target. If this target isn't defined, it will be added automatically.The actual test command to be run could be specified in the
MODMARIADB_TEST_CMD
. Default is similar to what bsd.port.mk(5) runs itself.The MariaDB server being started will listen on UNIX domain socket only, minimizing impact on running system. The path to socket is recorded in
MODMARIADB_TEST_SOCKET
. Any local user will be able to connect without password.If the
MODMARIADB_TEST_DBNAME
variable is set, the database with such name will be set up before running actual test command. Otherwise (default), the test is responsible to call mysqladmin(1) itself, if needed.The databases/mariadb,-server will get added to
TEST_DEPENDS
, but not to any other*_DEPENDS
. TheMODMARIADB_CLIENT_ARGS
andMODMARIADB_ADMIN_ARGS
variables hold arguments for mysql(1) and mysqladmin(1), respectively; those argument lists could be used in test scripts for connecting to test server, if they aren't satisfied by environment. - databases/postgresql
- Adds small framework for testing ports that require running Postgres.
Defines
MODPOSTGRESQL_TEST_TARGET
which consists actual commands to run indo-test
target. If this target isn't defined, it will be added automatically.The actual test command to be run could be specified in the
MODPOSTGRESQL_TEST_CMD
. Default is similar to what bsd.port.mk(5) runs itself.The Postgres server being started will listen on UNIX domain socket only, minimizing impact on running system. The path to directory where socket will be created is set by
MODPOSTGRESQL_TEST_PGHOST
, defaulting to ${WRKDIR}. Any local user will be able to connect without password.If the
MODPOSTGRESQL_TEST_DBNAME
variable is set, the database with such name will be set up before running actual test command. Otherwise (default), the test is responsible to call initdb(1) itself.The databases/postgresql,-server will get added to
TEST_DEPENDS
, but not to any other*_DEPENDS
. - devel/cmake
- Adds devel/cmake to
BUILD_DEPENDS
and fills upCONFIGURE_ARGS
,CONFIGURE_ENV
andMAKE_ENV
. Sets upconfigure
target. IfCONFIGURE_STYLE
was not set before, sets its value to `cmake'. Changes default value ofSEPARATE_BUILD
to `Yes' because modern CMake requires out-of-source build anyway. ChangesTEST_TARGET
to `test' as this is standard for CMake projects. Also this module has the following knobs:- MODCMAKE_WANTCOLOR
- If set to `Yes', CMake will colorize its output. Should not be used in ports Makefiles. Default value is `No'.
- MODCMAKE_VERBOSE
- If set to `Yes', CMake will print details during configure and build stages about exact command being run, etc. Should not be used in ports Makefiles. Default value is `Yes'.
- MODCMAKE_DEBUG
- If set to `Yes', CMake will produce a debug build instead of a release build. The exact effects on the build process depend on settings specified in the CMake config files. Default value is `No'.
- devel/cargo
- Automates download and compilation of dependencies of a Rust project using
cargo(1). During
fetch
, static dependencies ("crates") listed inMODCARGO_CRATES
are downloaded usingMODCARGO_DIST_SUBDIR
asDIST_SUBDIR
. Duringpost-extract
, crates defined inMODCARGO_CRATES
are moved to theMODCARGO_VENDOR_DIR
directory. Duringpost-patch
, crate-metadata are generated using devel/cargo-generate-vendor. WithCONFIGURE_STYLE
set to ‘cargo’, cargo is configured to useMODCARGO_VENDOR_DIR
instead of the standard crates-io network source. Finally, any crates listed inMODCARGO_CRATES_UPDATE
are updated.MODCARGO_RUSTFLAGS
can be used to pass custom flags to all rustc(1) invocations.lang/rust, devel/cargo and devel/cargo-generate-vendor are added to
BUILD_DEPENDS
. By defaultMASTER_SITES9
is used to download the crates.This module defines:
- MODCARGO_CARGOTOML
- Path to cargo manifest. Defaults to ${WRKSRC}/Cargo.toml.
- MODCARGO_CRATES
- Crates that will be downloaded by the module.
- MODCARGO_CRATES_UPDATE
- List of crates to update, overriding the version listed in Cargo.lock.
- MODCARGO_FEATURES
- List of features to be used when building.
- MODCARGO_VENDOR_DIR
- Name of the local directory for vendoring crates. Defaults to ${WRKSRC}/modcargo-crates.
This module adds three make(1) targets:
modcargo-metadata
- Rerun the generation of crates' metadata.
modcargo-gen-crates
- Generate the
MODCARGO_CRATES
list from Cargo.lock (a preliminary crates list is not required). modcargo-gen-crates-licenses
- Generate the
MODCARGO_CRATES
list with license information from crates present in theMODCARGO_VENDOR_DIR
directory.
- devel/dconf
- Sets
CONFIGURE_ARGS
,BUILD_DEPENDS
andRUN_DEPENDS
. This module is used by ports installing gsettings schemas under ${PREFIX}/share/glib-2.0/schemas/. It requires the following goo in the PLIST:@exec %D/bin/glib-compile-schemas %D/share/glib-2.0/schemas >/dev/null @unexec-delete %D/bin/glib-compile-schemas %D/share/glib-2.0/schemas >/dev/null
- devel/gconf2
- A link from
gconftool-2(1) to
true(1) will be put at the front of the
PATH
. SetsCONFIGURE_ARGS
,BUILD_DEPENDS
andRUN_DEPENDS
. According to the values ofMODGCONF2_LIBDEP
, setsLIB_DEPENDS
. User settings: setMODGCONF2_SCHEMAS_DIR
to the directory name under ${LOCALBASE}/share/schemas/ where schemas files will be installed. - devel/meson
- Adds devel/meson and
devel/ninja to
BUILD_DEPENDS
. Sets upconfigure
target. IfCONFIGURE_STYLE
was not set before, sets its value to `meson'. Changes default value ofSEPARATE_BUILD
to `Yes' because meson requires out-of-source build. Also this module has the following knob:- MODMESON_WANTCOLOR
- If set to `Yes', meson will colorize its output. Should not be used in ports Makefiles. Default value is `No'.
- devel/pmk
- Sets
CONFIGURE_SCRIPT
,CONFIGURE_ARGS
andMODPMK_configure
. It appends devel/pmk toBUILD_DEPENDS
. - devel/qmake
- This module automates usage of qmake, independently of the actual version
of Qt being used. This module requires that one of the
x11/qt3, x11/qt4 or
x11/qt5 to be used as well.
If
CONFIGURE_STYLE
was not set before, sets its value to ‘qmake’. IfCONFIGURE_STYLE
contains ‘qmake’ the module will define each of the do-build and do-install targets, unless port already defines one; also,SEPARATE_BUILD
will be set to ‘Yes’ unless it's already set to some value. Also, unlessNO_TEST
is set, the do-test target will be defined.The following variables could be used in qmake-based ports:
MODQMAKE_ARGS
- Additional arguments for qmake invocation. The module already defines some.
MODQMAKE_INSTALL_ROOT
- Root directory for fake install. Normally, it's a WRKINST, but some (broken) ports require another value, like PREFIX.
MODQMAKE_PROJECTS
- List of qmake project files to be used, relative to WRKSRC. Directories containing those projects could be used as well, see qmake documentation for details. Defaults to ‘.’, which means the (only) project in WRKSRC directory.
MODQMAKE_RECURSIVE
- If ‘Yes’, then qmake will be run recursively during
configure stage; otherwise, only projects mentioned in
MODQMAKE_PROJECTS
will be processed during configure stage, and their descendants will be visited during main build phase. Sometimes a qmake project processing depends on files generated by other qmake project during build, and recursive builds break this. For Qt4+ defaults to ‘Yes’, and Qt3 doesn't support recursive configuring. MODQMAKE_build
- Actual commands that module will use to build all
MODQMAKE_PROJECTS
provided. To be used in complicated cases, when port have to use its own do-build target or mix differentCONFIGURE_STYLE
values. MODQMAKE_install
- Same as for
MODQMAKE_build
, but used in do-install stage.
- devel/scons
- Adds devel/scons to
BUILD_DEPENDS
. SetsMODSCONS_BIN
andMODSCONS_ENV
. Also defines an overridableMODSCONS_FLAGS
. It provides ado-build
anddo-install
targets that can be overridden in the port Makefile. - font
- fortran
- Sets
MODFORTRAN_LIB_DEPENDS
,MODFORTRAN_WANTLIB
,MODFORTRAN_BUILD_DEPENDS
. SetMODFORTRAN_COMPILER
to `g77' or `gfortran', depending on what the port requires. The default is `g77'. The dependencies are chosen according toMODFORTRAN_COMPILER
. - gcc4
- If
COMPILER_VERSION
is not gcc4 (defined by /usr/share/mk/bsd.own.mk), and architecture is inMODGCC4_ARCHS
, then the gcc4 compilers will be put at the front of the path. By default, only C language support is included by this module. If other languages are needed, they must be listed inMODGCC4_LANGS
(e.g. c++, fortran). TheMODGCC4_VERSION
variable can be used to change the version of gcc. By default gcc 4.9 is used. IfMODGCC4_LANGS
contains c++, this module providesMODGCC4_CPPLIBDEP
andMODGCC4_CPPWANTLIB
. - gnu
- This module is documented in the main bsd.port.mk(5) manpage.
- imake
- This module is documented in the main bsd.port.mk(5) manpage.
- java
- Set
MODJAVA_VER=x.y
to use exactly the JDK x.y,MODJAVA_VER=x.y+
to use any x.y or higher version. SetMODJAVA_JRERUN=Yes
if the port only needs the JRE at runtime. The module setsJAVA_HOME
,ONLY_FOR_ARCHS
,MODJAVA_RUN_DEPENDS
,MODJAVA_SHARE_DIR
,MODJAVA_JAR_DIR
,MODJAVA_EXAMPLE_DIR
andMODJAVA_DOC_DIR
. It appends toBUILD_DEPENDS
,RUN_DEPENDS
,CATEGORIES
andSUBST_VARS
. IfMODJAVA_BUILD=ant
then this module providesMODJAVA_BUILD_DIR
,MODJAVA_BUILD_FILE
andMODJAVA_BUILD_TARGET_NAME
, as well as ado-build
target (if not already defined). It heedsNO_BUILD
. - lang/clang
- Similar to gcc3 and gcc4 modules. If architecture is in MODCLANG_ARCHS,
the CLang compilers will be put at the front of the path. By default, only
C language support is included by this module. If other languages are
needed, they must be listed in
MODCLANG_LANGS
(e.g. c++). SetsMODCLANG_VERSION
which is also appended toSUBST_VARS
. - lang/erlang
- lang/ghc
- Sets
ONLY_FOR_ARCHS
,MODGHC_VER
,BUILD_DEPENDS
, andRUN_DEPENDS
. Build and further actions are based on the list of values inMODGHC_BUILD
:- nort
- no runtime dependency on lang/ghc nor the hs-
prefix to
PKGNAME
will be added, - cabal
- get the typical Cabal targets defined,
- haddock
- generate API documentation using devel/haddock,
- register
- create and include register/unregister scripts,
- hackage
- the distfiles are available on Hackage.
Also affects
CATEGORIES
,CONFIGURE_STYLE
andSUBST_VARS
.do-build
,do-install
anddo-test
targets are provided if the port itself didn't set them. If register has been set, the PLIST needs to be modified in order to add the relevant @exec/@unexec lines. This module will run the Setup script and ensure the documentation will be built (if haddock has been set), and that the package is registered as a library usable by lang/ghc (if register has been set). Extra arguments and environment additions for the Setup configure command can be specified withMODGHC_SETUP_CONF_ARGS
andMODGHC_SETUP_CONF_ENV
. - lang/go
- Adds Go toolchain support. Requires
ALL_TARGET
to be set to canonical Go import path of port. (Module sets it automatically for ports that useGH_ACCOUNT
andGH_PROJECT
macros.)During execution of
pre-configure
target module moves source code from ${MODGO_SUBDIR} to ${WRKSRC}, subdirectory of ${MODGO_WORKSPACE} - specially-crafted Go workspace located at ${WRKDIR}/go. Duringdo-build
module calls “go install” withGOPATH
set to ${MODGO_WORKSPACE}, runs its output through sed to prevent writes outsideWRKDIR
sandbox and sends output to sh(1). Duringdo-install
it copies executables from ${MODGO_WORKSPACE}/bin to ${PREFIX}/bin, and/or directories ${MODGO_WORKSPACE}/pkg and ${MODGO_WORKSPACE}/src to ${PREFIX}/go, depending onMODGO_TYPE
contents.Sets
BUILD_DEPENDS
,RUN_DEPENDS
,ALL_TARGET
,TEST_TARGET
,ONLY_FOR_ARCHS
,SEPARATE_BUILD
, andWRKSRC
.Appends to
CATEGORIES
.Defines:
MODGO_TYPE
- Type of port. May be any combination of:
- bin
- ordinary binary, which should be installed to ${PREFIX}/bin,
- lib
- library, which should come with source code.
Defaults to bin.
MODGO_WORKSPACE
- Path to Go workspace set up for port build process. Defaults to ${WRKDIR}/go. See Go documentation for details.
MODGO_SUBDIR
- Path to Go source code within port's sources tarball. Defaults to ${WRKDIST}.
MODGO_SETUP_WORKSPACE
- Commands setting up Go workspace for building ports. By default,
happens during execution of
pre-configure
target. MODGO_BUILDDEP
- Controls whether contents of
MODGO_BUILD_DEPENDS
are appended to port'sBUILD_DEPENDS
. Defaults to Yes.
Additionally defines
MODGO_PACKAGES
,MODGO_SOURCES
andMODGO_TOOLS
(paths for installed Go packages, sources and tools respectively),MODGO_CMD
andMODGO_FLAGS
(source code build command and flags passed as its arguments),MODGO_LDFLAGS
,MODGO_BUILD_CMD
andMODGO_TEST_CMD
(commands for building and testing go packages; normally called with canonical Go package names as arguments),MODGO_{BUILD,INSTALL,TEST}_TARGET
andMODGO_{BUILD,RUN}_DEPENDS
. - lang/lua
- Sets
MODLUA_BIN
,MODLUA_DATADIR
,MODLUA_DEP
,MODLUA_DEP_VERSION
,MODLUA_DOCDIR
,MODLUA_EXAMPLEDIR
,MODLUA_INCL_DIR
,MODLUA_LIB
,MODLUA_LIBDIR
,MODLUA_VERSION
,MODLUA_WANTLIB
. Appends toCATEGORIES
. Also appends toBUILD_DEPENDS
, unlessNO_BUILD
has been set to Yes. Also appends toRUN_DEPENDS
, unlessMODLUA_RUNDEP
is set to No. AppendsMODLUA_VERSION
,MODLUA_LIB
,MODLUA_INCL_DIR
,MODLUA_EXAMPLEDIR
,MODLUA_DOCDIR
,MODLUA_LIBDIR
,MODLUA_DATADIR
,MODLUA_DEP
,MODLUA_DEP_VERSION
,MODLUA_BIN
toSUBST_VARS
.MODLUA_DEFAULT_VERSION
is set to 5.1.MODLUA_VERSION is set to
MODLUA_DEFAULT_VERSION
by default. Ports can be built with several lua versions. If no FLAVOR is set it defaults to MODLUA_DEFAULT_VERSION. Otherwise the FULLPKGNAME is adjusted, if MODLUA_SA is not set. In order to set a build, run or test dependency on a lua port, use the following, which will propagate the currently used flavor:MODLUA_BUILD_DEPENDS
,MODLUA_TEST_DEPENDS
,MODLUA_RUN_DEPENDS
. - lang/mono
- Sets
MODMONO_ONLY_FOR_ARCHS
,CONFIGURE_ENV
,MAKE_FLAGS
,MODMONO_BUILD_DEPENDS
andMODMONO_RUN_DEPENDS
. IfMODMONO_DEPS
is set to Yes, lang/mono is appended toBUILD_DEPENDS
andRUN_DEPENDS
.DLLMAP_FILES
defines in which files the module will substitute hardcoded shared library versions using apost-configure
target. - lang/node
- Adds common dependencies to
RUN_DEPENDS
andBUILD_DEPENDS
. Recognizes two additional types ofCONFIGURE_STYLE
s, "npm" and "npm ext". "npm ext" should be used for npm packages that contain C++ extensions which need to be compiled. "npm" should be used for other npm packages. If regression tests are included that can be run using devel/node-expresso, append "expresso" toCONFIGURE_STYLE
. devel/node-expresso will be appended toTEST_DEPENDS
and a defaultMODNODE_TEST_TARGET
will be defined, along with ado-test
target if it has not already been set. If "expresso" isn't appended toCONFIGURE_STYLE
,TEST_TARGET
will be set to "test". One of these twoCONFIGURE_STYLE
s should be used or the module doesn't affect anything exceptRUN_DEPENDS
andBUILD_DEPENDS
. RequiresNPM_NAME
to be set to the name of the npm package. UsesNPM_NAME
andNPM_VERSION
to setDISTNAME
, andPKGNAME
, andMASTER_SITES
. If the npm package depends on other npm packages, the npm package names it depends on should be listed inMODNODE_DEPENDS
. Adds defaultdo_build
anddo_install
tasks, and you can reference the default implementations viaMODNODE_BUILD_TARGET
andMODNODE_INSTALL_TARGET
. - lang/ocaml
- Appends to
BUILD_DEPENDS
andMAKE_ENV
. This selects a %%native%% plist fragment andocaml_native
property depending on whether the architecture supports native compilation. If dynamic linking is supported on the native architecture, the %%dynlink%% plist fragment andocaml_native_dynlink
property is set. WhenCONFIGURE_STYLE
is set to `oasis', overrides for thedo-build
,do-install
, anddo-test
targets are added. - lang/php
- Used for ports using PHP in some way: either extensions to PHP, or
software written in PHP. Sets
MODPHP_RUN_DEPENDS
,MODPHP_LIB_DEPENDS
,MODPHP_WANTLIB
,MODPHP_BIN
,MODPHP_PHPIZE
,MODPHP_PHP_CONFIG
,MODPHP_INCDIR
andMODPHP_LIBDIR
. Adds toRUN_DEPENDS
andBUILD_DEPENDS
unlessMODPHP_RUNDEP
orMODPHP_BUILDDEP
are set. IfMODPHP_DO_PHPIZE
is set, prepares a build environment for extensions that use phpize.Ports using PDO for database connectivity often have a choice of dependencies (pdo_sqlite, pdo_mysql, pdo_pgsql and others). The module constructs
MODPHP_PDO_DEPENDS
from the PDO types listed inMODPHP_PDO_ALLOWED
(defaulting to "sqlite mysql pgsql"). This can be added toRUN_DEPENDS
and allows any of these PDO packages to satisfy the dependency, withMODPHP_PDO_PREF
(sqlite by default) chosen if none are installed. - lang/php/pecl
- Used for ports for PHP PECL extensions. Sets default
MASTER_SITES
,HOMEPAGE
,EXTRACT_SUFX
,DESTDIRNAME
,MODPHP_DO_SAMPLE
,MODPHP_DO_PHPIZE
,AUTOCONF_VERSION
,AUTOMAKE_VERSION
,LIBTOOL_FLAGS
. Provides a defaultTEST_TARGET
andTEST_FLAGS
unlessNO_TEST
or ado-test
target is defined. Adds common dependencies toRUN_DEPENDS
andBUILD_DEPENDS
. Sets a defaultPKGNAME
and appends toCATEGORIES
. - lang/python
- Sets
MODPY_VERSION
,MODPY_BIN
,MODPY_INCDIR
,MODPY_LIBDIR
,MODPY_SITEPKG
,MODPY_SETUP
,MODPY_WANTLIB
,MODPY_LIB_DEPENDS
,MODPY_RUN_DEPENDS
,MODPY_BUILD_DEPENDS
andMODPY_ADJ_FILES
. Appends toRUN_DEPENDS
unlessMODPY_RUNDEP
is set to No. Appends toBUILD_DEPENDS
unlessMODPY_BUILDDEP
is set to No orNO_BUILD
is set to Yes.MODPY_VERSION
is the default version used by all python modules. Ports which use the setuptools module should setMODPY_SETUPTOOLS
to Yes. All ports that generate egg-info files should setMODPY_EGG_VERSION
to the version string used by the port's setup.py setup() function. Arguments can be passed to setup.py duringconfigure
withMODPY_SETUP_ARGS
. Extra arguments to the build and install commands can be passed viaMODPY_DISTUTILS_BUILDARGS
andMODPY_DISTUTILS_INSTALLARGS
. If any files have a python shebang line which needs to be replaced using MODPY_BIN, list them inMODPY_ADJ_FILES
. These are prefixed with WRKSRC and replaced automatically at the end ofpre-configure
. Also affectsCATEGORIES
,MAKE_ENV
,CONFIGURE_ENV
, andSUBST_VARS
. May affect thetest
target. IfMODPY_PI
is set to Yes it will setHOMEPAGE
andMASTER_SITES
. The subdirectory can be overridden withMODPY_PI_DIR
.Python 2.x places .pyc files in the same directory as the associated .py file. Python 3.x places these in a separate __pycache__ directory and uses an additional suffix. In some cases, an ABI tag is also used for names of compiled extensions. The python module defines variables to allow a single PLIST to be used for both versions. Generate or update the PLIST using the python3
FLAVOR
, then edit it to prefix any lines creatingMODPY_PYCACHE
directories withMODPY_COMMENT
. As python2 and python3 packages should permit being installed together, it may be necessary to suffix names of common binaries or directories, or split common files into a subpackage. If updating the PLIST without using the python3 flavor, take care not to remove ${MODPY_PYCACHE}, ${MODPY_PYC_MAGIC_TAG}, or ${MODPY_ABI_TAG} variables from the PLIST. - lang/ruby
- See ruby-module(5).
- lang/tcl
- Sets
MODTCL_VERSION
,MODTCL_BIN
,MODTCL_INCDIR
,MODTCL_LIBDIR
,MODTCL_BUILD_DEPENDS
,MODTCL_RUN_DEPENDS
,MODTCL_LIB
,MODTCL_LIB_DEPENDS
, andMODTCL_CONFIG
.MODTCL_VERSION
is the default version used by all Tcl ports and may be overridden. ProvidesMODTCL_TCLSH_ADJ
andMODTCL_WISH_ADJ
shell fragments to patch the interpreter path in executable scripts. Also affectsCATEGORIES
andSUBST_VARS
. - perl
- This module is documented in the main bsd.port.mk(5) manpage.
- security/heimdal
- A link from ${LOCALBASE}/heimdal/bin/krb5-config to
krb5-config(1) will be put at the front of the path. Sets
LIB_DEPENDS
andWANTLIB
according to the values ofMODHEIMDAL_LIB_DEPENDS
, andMODHEIMDAL_WANTLIB
. - textproc/intltool
- Sets
MODINTLTOOL_OVERRIDE
. textproc/intltool is added toBUILD_DEPENDS
.MODINTLTOOL_OVERRIDE
changes the paths ofINTLTOOL_EXTRACT
,INTLTOOL_MERGE
andINTLTOOL_UPDATE
to use the installed versions of intltool-extract, intltool-merge and intltool-update, instead of the version's packages into the distfile of the port using this module. Also affectsCONFIGURE_ENV
,MAKE_ENV
andMAKE_FLAGS
by appendingMODINTLTOOL_OVERRIDE
to them. - www/drupal7
- Can be used to install plugins (default), themes if
MODDRUPAL_THEME
is yes, or languages packs ifDRUPAL_LANG
is set to the desired language.The module may set or add to default values for
HOMEPAGE
,MASTER_SITES
,PREFIX
,DISTNAME
,DIST_SUBDIR
,CATEGORIES
,PKGNAME
,PKG_ARCH
,WRKDIST
,RUN_DEPENDS
. Drupal modules normally don't have any build part, just an installation part that defaults to copying the plugin/theme/language files into the right location throughMODDRUPAL_INSTALL
.The module sets
DRUPAL
to drupal7,DRUPAL_ROOT
to htdocs/${DRUPAL}DRUPAL_MODS
to ${DRUPAL_ROOT}/site/all/modulesDRUPAL_THEMES
to ${DRUPAL_ROOT}/site/all/themes andDRUPAL_TRANSLATIONS
to ${DRUPAL_ROOT}/profiles/standard/translations. So, by default, modules and themes are installed for all sites, and translations are activated at install.DRUPAL_OWNER
,DRUPAL_GROUP
are set to root, daemon, since drupal doesn't need to write to any file except the files/ directory and the site settings (those belong to www instead).Most modules are actually separate projects on the drupal site. If
MODDRUPAL_PROJECT
is set,HOMEPAGE
will lead to the corresponding project. IfMODDRUPAL_VERSION
is also set,DISTNAME
will default to ${MODDRUPAL_PROJECT}-7.x-${MODDRUPAL_VERSION}, MODDRUPAL_PKGNAME will default to ${MODDRUPAL_PROJECT} andPKGNAME
will default to drupal7-${MODDRUPAL_PKGNAME}-${MODDRUPAL_VERSION}.Translations are handled by setting
DRUPAL_LANG
to the language letter code, and by settingLANGFILES
to a list of module names/version pairs.With drupal7, all translations have been put in separate .po files. It has been deemed simplest to pack all translations for a given language into a single package, since translations for non installed modules won't affect anything.
- www/mozilla
- Sets
PKGNAME
,HOMEPAGE
,MASTER_SITES
,DISTNAME
,USE_GMAKE
, andONLY_FOR_ARCHS
.EXTRACT_SUFX
defaults to .tar.bz2.Adds common dependencies to
LIB_DEPENDS
,WANTLIB
,RUN_DEPENDS
andBUILD_DEPENDS
. Sets commonCONFIGURE_ARGS
,MAKE_ENV
andCONFIGURE_ENV
. SetsMOB
variable as source directory andMOZ
as target directory withindo-install
.Individual port Makefile must set
MOZILLA_PROJECT
,MOZILLA_CODENAME
,MOZILLA_VERSION
,MOZILLA_BRANCH
,MOZILLA_LIBS
andMOZILLA_DATADIRS
variables. Port can also append values toMOZILLA_SUBST_FILES
which contains the list of files to runSUBST_CMD
on duringpre-configure
, andMOZILLA_AUTOCONF_DIRS
which contains the list of dirs whereAUTOCONF
will be run duringpre-configure
. - www/pear
- Used for PHP PEAR ports. Sets default
MASTER_SITES
,EXTRACT_SUFX
,PKGNAME
. SetsPREFIX
to /var/www. SetsNO_TEST
unless ado-test
target is defined. Adds common dependencies toRUN_DEPENDS
andBUILD_DEPENDS
, setsMAKE_FILE
andFAKE_FLAGS
appropriately. MakesPEAR_LIBDIR
andPEAR_PHPBIN
available for use in the port. Sets a defaultPKGNAME
and appends toCATEGORIES
. - www/plone
- Sets
MODPLONE_VERSION
andMODZOPE_VERSION
.MODPLONE_VERSION
is the default version used by all Plone ports and may be overridden. It appends www/plone toRUN_DEPENDS
and also setsNO_TEST
to Yes. - x11/gnome
- This module has full support for the gnu,
simple and cmake
CONFIGURE_STYLE.
If both
GNOME_PROJECT
andGNOME_VERSION
are set, this module definesDISTNAME
,VERSION
,MASTER_SITES
, adds x11/gnome toCATEGORIES
andEXTRACT_SUFX
will default to .tar.xz if unset. UnlessNO_BUILD=Yes
, textproc/intltool is also appended toMODULES
and when CONFIGURE_STYLE is set to gnu or simple,USE_GMAKE
is set to "Yes".When CONFIGURE_STYLE is set to gnu or simple, if none of
AUTOCONF_VERSION
norAUTOMAKE_VERSION
are defined, then "--disable-maintainer-mode" is appended toCONFIGURE_ARGS
. When CONFIGURE_STYLE is set to cmake, "-DENABLE_MAINTAINER_MODE=OFF" and -DSYSCONF_INSTALL_DIR=${SYSCONFDIR} are appended to CONFIGURE_ARGS.MODGNOME_CPPFLAGS and MODGNOME_LDFLAGS can be used to add compiler and linker flags.
CPPFLAGS="-I${LOCALBASE}/include"
andLDFLAGS="-L${LOCALBASE}/lib"
are always appended toCONFIGURE_ENV
.Certain build/run dependencies and configure arguments and environment can be set by appending desktop-file-utils, docbook, gobject-introspection, gtk-update-icon-cache, shared-mime-info, vala and/or yelp to
MODGNOME_TOOLS
. They are disabled otherwise. IfMODGNOME_TOOLS
is set to desktop-file-utils, a dependency on devel/desktop-file-utils is appended toMODGNOME_RUN_DEPENDS
and a link to /usr/bin/true is created under ${WRKDIR}/bin/desktop-file-validate. IfMODGNOME_TOOLS
is set to docbook, textproc/docbook-xsl is appended toMODGNOME_BUILD_DEPENDS
. This option is used when the generation of the man pages included in the source tarball requires docbook XML/SGML/XSL definitions and stylesheets. IfMODGNOME_TOOLS
is set to gtk-update-icon-cache, a dependency on x11/gtk+3,-guic is appended toMODGNOME_RUN_DEPENDS
. IfMODGNOME_TOOLS
is set to shared-mime-info, a dependency on misc/shared-mime-info is appended toMODGNOME_RUN_DEPENDS
and a link to /usr/bin/true is created under ${WRKDIR}/bin/update-mime-database. IfMODGNOME_TOOLS
is set to yelp, textproc/itstool and x11/gnome/doc-utils are appended toMODGNOME_BUILD_DEPENDS
. Furthermore, x11/gnome/yelp is appended toMODGNOME_RUN_DEPENDS
ifMODGNOME_TOOLS
also contains "desktop-file-utils" This option is to be used when any files are installed into share/gnome/help/ or page files are installed into share/help/.MODGNOME_BUILD_DEPENDS
andMODGNOME_RUN_DEPENDS
are appended to the correspondingBUILD_DEPENDS
andRUN_DEPENDS
.Some tools require the following goo in the PLIST:
desktop-file-utils
@exec %D/bin/update-desktop-database @unexec-delete %D/bin/update-desktop-database
gtk-update-icon-cache ($icon-theme is the theme directory)
@exec %D/bin/gtk-update-icon-cache -q -t %D/share/icons/$icon-theme @unexec-delete %D/bin/gtk-update-icon-cache -q -t %D/share/icons/$icon-theme
shared-mime-info
@exec %D/bin/update-mime-database %D/share/mime @unexec-delete %D/bin/update-mime-database %D/share/mime
- x11/gnustep
- x11/kde
- Used for building KDE3-enabled ports. Main variables there is
MODKDE_VERSION
, which defines what patches and tweaks should be applied, depending of exact KDE version the ported software is build against of. - x11/kde4
- Required for building KDE4-enabled ports. Main variables are: MODKDE4_USE,
MODKDE4_VERSION, MODKDE4_DEP_DIR, MODKDE4_DEP_VERSION, MODKDE4_FLAVOR.
It's used both for KDE4 SC itself and for software built on top of it,
e.g., Digikam. This module supports several KDE4 trees at the same time,
see below. The following variables are designed to be used in both types
of ports:
MODKDE4_USE
- Defines the core components of KDE4 to be used by the port. Could have
zero or more of the following values, in any order:
‘libs’, ‘runtime’, ‘pim’,
‘games’, ‘workspace’. Could be forced to
be empty, this will mean no automated dependencies. If
‘libs’ is specified, no dependencies on runtime
(kde-runtime or kdepim-runtime) will be recorded. The
‘workspace’ component implies ‘runtime’.
The ‘games’ component is to be used by games and affects
default HOMEPAGE, too. If neither ‘libs’ or
‘runtime’ are specified, the ‘runtime’ is
implied. If both ‘libs’ and ‘runtime’ are
specified, then ‘runtime’ takes precedence (actually,
it's a libs+ anyway). The ‘pim libs’ combination adds
dependencies on both kdelibs and kdepimlibs, and ‘pim runtime
(’ or just ‘pim’) also adds dependencies on both
kde-runtime and kdepim-runtime. Defaults to ‘libs’ when
MODKDE4_RESOURCES
is set to ‘Yes’, and ‘runtime’ otherwise. MODKDE4_DEP_DIR
- Expands to ‘x11/kdeVERSION’ where version depends on
current
MODKDE4_VERSION
, see below. Read-only. MODKDE4_DEP_VERSION
- Expands to a string to be used in dependency lines, see examples in x11/kde4/* ports. Read-only.
MODKDE4_RESOURCES
- Should be set to ‘Yes’ for ports that only provide
non-executable stuff like icons, localization files and so on. Affects
FLAVORS
,MODKDE4_NO_QT
,MODKDE4_USE
,MODULES
,PKG_ARCH
andSUBST_VARS
variables. Defaults to ‘No’. MODKDE4_INCLUDE_DIR
- Path where KDE4 headers to be placed/searched for, relative to
PREFIX
. Read-only. MODKDE4_LIB_DIR
- Path where KDE4 headers to be placed/searched for, relative to
PREFIX
. Read-only. KDE4LIB
- Shorter synonym for
MODKDE4_LIB_DIR
, to be used in plists andWANTLIB
declarations. Read-only. MODKDE4_FIX_GETTEXT
- If set to ‘Yes’, adds an additional step before building port that searches for KDE-specific calls of GETTEXT_PROCESS_PO_FILES() CMake command and tweaks them to be compatible with the one from FindGettext.cmake module provided by CMake itself. Defaults to ‘Yes’.
MODKDE4_SYSCONF_FILES
- Some KDE ports install files under
${SYSCONFDIR}. We want to have them under
${PREFIX}/share/examples
or such, and just be @sample'd under ${SYSCONFDIR}. So add ‘file/dir destination’ pairs to this variable, and appropriate @sample lines to packing list, e.g.:# in Makefile: MODKDE4_SYSCONF_FILES = dbus-1 share/examples # in PLIST: share/examples/dbus-1/system.d/org.kde.baloo.filewatch.conf @sample ${SYSCONFDIR}/dbus-1/system.d/org.kde.baloo.filewatch.conf
The following variables are mostly used only inside KDE4 SC:
- MODKDE4_LIB_LINKS
- If set to ‘Yes’, soft links for shared libraries in ${PREFIX}/lib to ${MODKDE4_LIB_DIR} will be created. Used to distinguish libraries from different KDE versions (3, 4...). Defaults to ‘No’.
- KDE4_ONLY
- If set to ‘Yes’, sets the
dpb(1) tag to ‘kde4’. Defaults to
‘No’ when
MODKDE4_USE
is empty, and to ‘Yes’ otherwise.
The following variables are likely to be used only outside KDE4 SC:
- MODKDE4_NO_QT
- If set to ‘Yes’, avoids automatic addition of x11/qt4 to
MODULES
.
The x11/kde4 module supports co-existence of different KDE4 SC version ports subtrees. There always is a so-called stable tree in ${PORTSDIR}/x11/kde4 and additional trees are placed in ${PORTSDIR}/x11/kdeXYZ, where ‘XYZ’ correspond to the ‘X.Y.Z’ KDE version. So, say, KDE 4.12.4 tree should be placed in ${PORTSDIR}/x11/kde4124 directory. The process of preparing a new KDE SC version subtree is automated, just use kde-release-helper script:
cd ${PORTSDIR}/x11/kde4 ./kde-release-helper prepare 4.12.4
REVISION
marks, remove distinfo files and so on.To access the new version then you'll need to add appropriate values at the top of x11/kde4 module file itself. Then you be able to use automatically created ‘kdeXYZ’
FLAVOR
to reference corresponding KDE4 SC version outside x11/kde4*.The x11/kde4 module sets the following variables unless they're already set by a port:
CONFIGURE_STYLE
,EXTRACT_SUFX
,ONLY_FOR_ARCHS
,PORTHOME
, andSEPARATE_BUILD
.The x11/kde4 module modifies the following variables if needed:
BUILD_DEPENDS
,CONFIGURE_ARGS
,CONFIGURE_ENV
,LIB_DEPENDS
,RUN_DEPENDS
, andWANTLIB
.The x11/kde4 module automatically adds devel/cmake to
MODULES
unlessNO_BUILD
is set to ‘Yes’. The x11/kde4 module automatically adds x11/qt4 toMODULES
unlessMODKDE4_NO_QT
is set to ‘Yes’. The x11/kde4 module automatically adds gcc4 toMODULES
unlessMODKDE4_RESOURCES
is set to ‘Yes’. - x11/qt3, x11/qt4 and x11/qt5
- All qt* modules share a common
MODQT_*
namespace for simple ports. The qt3 module also defines the same variables underMODQT3_*
, the qt4 module also defines the same variables underMODQT4_*
and the qt5 module also defines the same variables underMODQT5_*
, to allow ports to use both modules, such as print/poppler.Those modules define
MODQT*_LIBDIR
as the libraries location,MODQT*_INCDIR
as the include files location,MODQT*_QTDIR
as the global qt directory location,MODQT*_CONFIGURE_ARGS
as standard GNU configure-style parameters to locate the include and libraries.The location of Qt-specific tools
lrelease
,moc
,qmake
anduic
is available throughMODQT*_LRELEASE
,MODQT*_MOC
,MODQT*_QMAKE
andMODQT*_UIC
.MODQT*_OVERRIDE_UIC
controls whether the default setup will force a value ofUIC
or not. The value ofMOC
is always forced to ${MODQT*_MOC}.In most cases the devel/qmake module should be used instead of using
MODQT*_QMAKE
directly.qt4 includes pkg-config(1) files under a specific location recorded in
MODQT_PKG_CONFIG_PATH
. Qt3 requires the use ofMODQT3_PLUGINS
to correctly locate plugins.The modules add to
CONFIGURE_ENV
,MAKE_ENV
andMAKE_FLAGS
. They define appropriateMODQT*_LIB_DEPENDS
andMODQT*_WANTLIB
.Note that Qt 4 and Qt 5 has their code split over several libraries. For the qt4 module the basic
WANTLIB
only refers to QtCore, and other libraries should be added as needed. The qt5 module doesn't setMODQT*_WANTLIB
at all. Also, Qt 5 consists of many so called Qt modules, and qt5 port module only refers to qtbase Qt 5 module; other Qt modules should be added toLIB_DEPENDS
,BUILD_DEPENDS
orRUN_DEPENDS
manually. - x11/tk
- Sets
MODTK_VERSION
,MODTK_BIN
,MODTK_INCDIR
,MODTK_LIBDIR
,MODTK_BUILD_DEPENDS
,MODTK_RUN_DEPENDS
,MODTK_LIB
,MODTK_LIB_DEPENDS
, andMODTK_CONFIG
.MODTK_VERSION
is the default version used by all Tk ports and may be overridden. Automatically adds the lang/tcl module, provides a defaultMODTCL_VERSION
to matchMODTK_VERSION
, and affectsCATEGORIES
andSUBST_VARS
. Note theMODTCL_WISH_ADJ
shell fragment in the lang/tcl module. - x11/xfce4
- Sets
DIST_SUBDIR
,EXTRACT_SUFX
,CONFIGURE_STYLE
,CONFIGURE_ENV
andUSE_GMAKE
. IfMODXFCE_ICON_CACHE
is set to yes, it adds x11/gtk+3,-guic toRUN_DEPENDS
. UnlessXFCE_NO_SRC
is set, textproc/intltool is added toMODULES
. Also affectsCATEGORIES
.Xfce ports can be divided into five categories: core libraries and applications, goodies, artwork, thunar plugins, and panel plugins.
HOMEPAGE
,MASTER_SITES
andDISTNAME
are built usingXFCE_VERSION
(which defaults toXFCE_DESKTOP_VERSION
if not set) and eitherXFCE_PROJECT
,XFCE_GOODIE
,XFCE_ARTWORK
,THUNAR_PLUGIN
orXFCE_PLUGIN
. One of the latter has to be provided by the port Makefile.