OpenBSD manual page server

Manual Page Search Parameters
PORT-MODULES(5) File Formats Manual PORT-MODULES(5)

port-modules — documentation and conventions used in port modules

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 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.

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.

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.

There is a post-extract hook that can be activated by defining MODFOO_post-extract. It will be run right after post-extract.
There is a post-patch hook that can be activated by defining MODFOO_post-patch. It will be run right after post-patch.
There is a gen hook that can be activated by defining MODFOO_gen. It will be run right after do-gen and before REORDER_DEPENDENCIES touches things.
There is a pre-configure hook that can be activated by defining MODFOO_pre-configure. It will be run right after pre-configure. The normal do-configure behavior is to invoke all MODFOO_configure contents that are defined in CONFIGURE_STYLE. By default, configure will do nothing.

Some CONFIGURE_STYLE values, namely perl, gnu, imake, and autoconf, will automatically import the correct module. User-defined modules must both add to CONFIGURE_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. If do-configure is overridden, normal hook processing will not happen.

There is a pre-fake hook that can be activated by defining MODFOO_pre-fake. This will be invoked right after mtree(8), and before the normal pre-fake behavior.

This can occasionally be used for ports that require some specific fake installation setup that will be provided by runtime dependencies.

There is a post-install hook that can be activated by defining MODFOO_post-install. This will be invoked at the end of install, right after the normal post-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:

That way, if several modules require specific actions for those targets, the end user can choose the appropriate order in which to run the actions: 
do-build:
	@${MODBAR_BUILD_TARGET}
	@${MODFOO_BUILD_TARGET}
	...

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.

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.

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 default PKGNAME. Also affects TEST_DEPENDS, CONFIGURE_STYLE, PKG_ARCH, and CATEGORIES.

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, and CPAN_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 the post-install target if none has been defined to install the examples, otherwise MODCPAN_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 in do-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. The MODMARIADB_CLIENT_ARGS and MODMARIADB_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 in do-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 up CONFIGURE_ARGS, CONFIGURE_ENV and MAKE_ENV. Sets up configure target. If CONFIGURE_STYLE was not set before, sets its value to `cmake'. Changes default value of SEPARATE_BUILD to `Yes' because modern CMake requires out-of-source build anyway. Changes TEST_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'.
Also, ‘nojunk’ is added to DPB_PROPERTIES because CMake's include files parser cheats too much.
devel/cargo
Automates download and compilation of dependencies of a Rust project using cargo(1). During fetch, static dependencies ("crates") listed in MODCARGO_CRATES are downloaded using MODCARGO_DIST_SUBDIR as DIST_SUBDIR. During post-extract, crates defined in MODCARGO_CRATES are moved to the MODCARGO_VENDOR_DIR directory. During post-patch, crate-metadata are generated using devel/cargo-generate-vendor. With CONFIGURE_STYLE set to ‘cargo’, cargo is configured to use MODCARGO_VENDOR_DIR instead of the standard crates-io network source. Finally, any crates listed in MODCARGO_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 default MASTER_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:

Rerun the generation of crates' metadata.
Generate the MODCARGO_CRATES list from Cargo.lock (a preliminary crates list is not required).
Generate the MODCARGO_CRATES list with license information from crates present in the MODCARGO_VENDOR_DIR directory.
devel/dconf
Sets CONFIGURE_ARGS, BUILD_DEPENDS and RUN_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. Sets CONFIGURE_ARGS, BUILD_DEPENDS and RUN_DEPENDS. According to the values of MODGCONF2_LIBDEP, sets LIB_DEPENDS. User settings: set MODGCONF2_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 up configure target. If CONFIGURE_STYLE was not set before, sets its value to `meson'. Changes default value of SEPARATE_BUILD to `Yes' because meson requires out-of-source build. If CONFIGURE_STYLE is 'meson', MODMESON_CONFIGURE_ARGS and MODMESON_CONFIGURE_ENV will add default values to CONFIGURE_ARGS and CONFIGURE_ENV. 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 and MODPMK_configure. It appends devel/pmk to BUILD_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’. If CONFIGURE_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, unless NO_TEST is set, the do-test target will be defined.

The following variables could be used in qmake-based ports:

Additional arguments for qmake invocation. The module already defines some.
Root directory for fake install. Normally, it's a WRKINST, but some (broken) ports require another value, like PREFIX.
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.
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.
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 different CONFIGURE_STYLE values.
Same as for MODQMAKE_build, but used in do-install stage.
devel/scons
Adds devel/scons to BUILD_DEPENDS. Sets MODSCONS_BIN and MODSCONS_ENV. Also defines an overridable MODSCONS_FLAGS. It provides a do-build and do-install targets that can be overridden in the port Makefile.
font
Used for ports which primarily install fonts. Affects PKG_ARCH and EXTRACT_SUFX. Appends to CATEGORIES. When TYPEFACE is set in combination with V or VERSION it sets PKGNAME. TYPEFACE should be set to the name of the typeface. This sets FONTDIR using said typeface name. FONTTYPES defaults to `ttf' but can be set to include the extenions of fonts which are to be installed. Also sets FONT_DISTDIR. A do-install target is provided if the port tself does not provide it.
fortran
Sets MODFORTRAN_LIB_DEPENDS, MODFORTRAN_WANTLIB, MODFORTRAN_BUILD_DEPENDS. Set MODFORTRAN_COMPILER to `gfortran', or `flang', depending on what the port requires. The default is `gfortran'. The dependencies are chosen according to MODFORTRAN_COMPILER.
gcc4
If COMPILER_VERSION is not gcc4 (defined by /usr/share/mk/bsd.own.mk), and architecture is in MODGCC4_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 in MODGCC4_LANGS (e.g. c++, fortran). The MODGCC4_VERSION variable can be used to change the version of gcc. By default gcc 4.9 is used. If MODGCC4_LANGS contains c++, this module provides MODGCC4_CPPLIBDEP and MODGCC4_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. Set MODJAVA_JRERUN=Yes if the port only needs the JRE at runtime. The module sets JAVA_HOME, ONLY_FOR_ARCHS, MODJAVA_RUN_DEPENDS, MODJAVA_SHARE_DIR, MODJAVA_JAR_DIR, MODJAVA_EXAMPLE_DIR and MODJAVA_DOC_DIR. It appends to BUILD_DEPENDS, RUN_DEPENDS, CATEGORIES and SUBST_VARS. If MODJAVA_BUILD=ant then this module provides MODJAVA_BUILD_DIR, MODJAVA_BUILD_FILE and MODJAVA_BUILD_TARGET_NAME, as well as a do-build target (if not already defined). It heeds NO_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++). Sets MODCLANG_VERSION which is also appended to SUBST_VARS.
lang/erlang
 
lang/ghc
Sets ONLY_FOR_ARCHS, MODGHC_VER, BUILD_DEPENDS, and RUN_DEPENDS. Build and further actions are based on the list of values in MODGHC_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 and SUBST_VARS. do-build, do-install and do-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 with MODGHC_SETUP_CONF_ARGS and MODGHC_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 use GH_ACCOUNT and GH_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. During do-build module calls “go install” with GOPATH set to ${MODGO_WORKSPACE}, runs its output through sed to prevent writes outside WRKDIR sandbox and sends output to sh(1). During do-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 on MODGO_TYPE contents.

Sets BUILD_DEPENDS, RUN_DEPENDS, ALL_TARGET, TEST_TARGET, ONLY_FOR_ARCHS, SEPARATE_BUILD, and WRKSRC.

Appends to CATEGORIES.

Defines:

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.

Path to Go workspace set up for port build process. Defaults to ${WRKDIR}/go. See Go documentation for details.
Path to Go source code within port's sources tarball. Defaults to ${WRKDIST}.
Commands setting up Go workspace for building ports. By default, happens during execution of pre-configure target.
Controls whether contents of MODGO_BUILD_DEPENDS are appended to port's BUILD_DEPENDS. Defaults to Yes.
is the module name as defined in the go.mod file contained in a project. If this is set, MODGO_MODULES, MODGO_MODFILES and MODGO_VERSION need to be defined as well. Setting this will also set ALL_TARGET. When MODGO_MODFILES is set, and a "cmd" directory is found in WRKSRC, "cmd/..." is appended to ALL_TARGET in do-build automatically.
Sets the specific version of a Go module to use. For example: v0.1.3.
List of modules and their specific versions that an application depends on.
List of go.mod files and their versions that are required for dependency resolution. These are required by Go to determine the full dependency graph.

Additionally defines MODGO_PACKAGES, MODGO_SOURCES and MODGO_TOOLS (paths for installed Go packages, sources and tools respectively), MODGO_CMD and MODGO_FLAGS (source code build command and flags passed as its arguments), MODGO_LDFLAGS, MODGO_BUILD_CMD and MODGO_TEST_CMD (commands for building and testing go packages; normally called with canonical Go package names as arguments), MODGO_{BUILD,INSTALL,TEST}_TARGET and MODGO_{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 to CATEGORIES. Also appends to BUILD_DEPENDS, unless NO_BUILD has been set to Yes. Also appends to RUN_DEPENDS, unless MODLUA_RUNDEP is set to No. Appends MODLUA_VERSION, MODLUA_LIB, MODLUA_INCL_DIR, MODLUA_EXAMPLEDIR, MODLUA_DOCDIR, MODLUA_LIBDIR, MODLUA_DATADIR, MODLUA_DEP, MODLUA_DEP_VERSION, MODLUA_BIN to SUBST_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 and MODMONO_RUN_DEPENDS. If MODMONO_DEPS is set to Yes, lang/mono is appended to BUILD_DEPENDS and RUN_DEPENDS. DLLMAP_FILES defines in which files the module will substitute hardcoded shared library versions using a post-configure target.
lang/node
Adds common dependencies to RUN_DEPENDS and BUILD_DEPENDS. Recognizes two additional types of CONFIGURE_STYLEs, "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" to CONFIGURE_STYLE. devel/node-expresso will be appended to TEST_DEPENDS and a default MODNODE_TEST_TARGET will be defined, along with a do-test target if it has not already been set. If "expresso" isn't appended to CONFIGURE_STYLE, TEST_TARGET will be set to "test". One of these two CONFIGURE_STYLEs should be used or the module doesn't affect anything except RUN_DEPENDS and BUILD_DEPENDS. Requires NPM_NAME to be set to the name of the npm package. Uses NPM_NAME and NPM_VERSION to set DISTNAME, and PKGNAME, and MASTER_SITES. If the npm package depends on other npm packages, the npm package names it depends on should be listed in MODNODE_DEPENDS. Adds default do_build and do_install tasks, and you can reference the default implementations via MODNODE_BUILD_TARGET and MODNODE_INSTALL_TARGET.
lang/ocaml
Appends to BUILD_DEPENDS and MAKE_ENV. This selects a %%native%% plist fragment and ocaml_native property depending on whether the architecture supports native compilation. If dynamic linking is supported on the native architecture, the %%dynlink%% plist fragment and ocaml_native_dynlink property is set. When CONFIGURE_STYLE is set to `oasis', overrides for the do-build, do-install, and do-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 and MODPHP_LIBDIR. Adds to RUN_DEPENDS and BUILD_DEPENDS unless MODPHP_RUNDEP or MODPHP_BUILDDEP are set. If MODPHP_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 in MODPHP_PDO_ALLOWED (defaulting to "sqlite mysql pgsql"). This can be added to RUN_DEPENDS and allows any of these PDO packages to satisfy the dependency, with MODPHP_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 default TEST_TARGET and TEST_FLAGS unless NO_TEST or a do-test target is defined. Adds common dependencies to RUN_DEPENDS and BUILD_DEPENDS. Sets a default PKGNAME and appends to CATEGORIES.
lang/python
Sets MODPY_VERSION, MODPY_BIN, MODPY_INCDIR, MODPY_LIBDIR, MODPY_SITEPKG, MODPY_SETUP, MODPY_TEST_DIR, MODPY_TEST_LOCALE, MODPY_WANTLIB, MODPY_LIB_DEPENDS, MODPY_RUN_DEPENDS, MODPY_TEST_DEPENDS, MODPY_BUILD_DEPENDS, and MODPY_ADJ_FILES. Appends to RUN_DEPENDS unless MODPY_RUNDEP is set to No. Appends to BUILD_DEPENDS unless MODPY_BUILDDEP is set to No or NO_BUILD is set to Yes. Appends to TEST_DEPENDS if MODPY_PYTEST is set to Yes unless MODPY_TESTDEP is set to No. Appends MODPY_TEST_LOCALE to TEST_ENV. Changes to the directory specified in MODPY_TEST_DIR, by default WRKSRC, before running tests. MODPY_VERSION is the default version used by all python modules. Ports which use the setuptools module should set MODPY_SETUPTOOLS to Yes. Ports which use the pytest module should set MODPY_PYTEST to Yes. Arguments can be passed to pytest during test with MODPY_PYTEST_ARGS. All ports that generate egg-info files should set MODPY_EGG_VERSION to the version string used by the () function in the port's setup.py. Arguments can be passed to setup.py during configure with MODPY_SETUP_ARGS. Extra arguments to the build and install commands can be passed via MODPY_DISTUTILS_BUILDARGS and MODPY_DISTUTILS_INSTALLARGS. If any files have a python shebang line which needs to be replaced using MODPY_BIN, list them in MODPY_ADJ_FILES. These are prefixed with WRKSRC and replaced automatically at the end of pre-configure. Also affects CATEGORIES, MAKE_ENV, CONFIGURE_ENV, and SUBST_VARS. May affect the test target. If MODPY_PI is set to Yes it will set HOMEPAGE and MASTER_SITES. The subdirectory can be overridden with MODPY_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 creating MODPY_PYCACHE directories with MODPY_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, and MODTCL_CONFIG. MODTCL_VERSION is the default version used by all Tcl ports and may be overridden. Provides MODTCL_TCLSH_ADJ and MODTCL_WISH_ADJ shell fragments to patch the interpreter path in executable scripts. Also affects CATEGORIES and SUBST_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 and WANTLIB according to the values of MODHEIMDAL_LIB_DEPENDS, and MODHEIMDAL_WANTLIB.
textproc/intltool
Sets MODINTLTOOL_OVERRIDE. textproc/intltool is added to BUILD_DEPENDS. MODINTLTOOL_OVERRIDE changes the paths of INTLTOOL_EXTRACT, INTLTOOL_MERGE and INTLTOOL_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 affects CONFIGURE_ENV, MAKE_ENV and MAKE_FLAGS by appending MODINTLTOOL_OVERRIDE to them.
www/drupal7
Can be used to install plugins (default), themes if MODDRUPAL_THEME is yes, or languages packs if DRUPAL_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 through MODDRUPAL_INSTALL.

The module sets DRUPAL to drupal7, DRUPAL_ROOT to htdocs/${DRUPAL} DRUPAL_MODS to ${DRUPAL_ROOT}/site/all/modules DRUPAL_THEMES to ${DRUPAL_ROOT}/site/all/themes and DRUPAL_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. If MODDRUPAL_VERSION is also set, DISTNAME will default to ${MODDRUPAL_PROJECT}-7.x-${MODDRUPAL_VERSION}, MODDRUPAL_PKGNAME will default to ${MODDRUPAL_PROJECT} and PKGNAME will default to drupal7-${MODDRUPAL_PKGNAME}-${MODDRUPAL_VERSION}.

Translations are handled by setting DRUPAL_LANG to the language letter code, and by setting LANGFILES 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, and ONLY_FOR_ARCHS. EXTRACT_SUFX defaults to .tar.bz2.

Adds common dependencies to LIB_DEPENDS, WANTLIB, RUN_DEPENDS and BUILD_DEPENDS. Sets common CONFIGURE_ARGS, MAKE_ENV and CONFIGURE_ENV. Sets MOB variable as source directory and MOZ as target directory within do-install.

Individual port Makefile must set MOZILLA_PROJECT, MOZILLA_CODENAME, MOZILLA_VERSION, MOZILLA_BRANCH, MOZILLA_LIBS and MOZILLA_DATADIRS variables. Port can also append values to MOZILLA_SUBST_FILES which contains the list of files to run SUBST_CMD on during pre-configure, and MOZILLA_AUTOCONF_DIRS which contains the list of dirs where AUTOCONF will be run during pre-configure.

www/pear
Used for PHP PEAR ports. Sets default MASTER_SITES, EXTRACT_SUFX, PKGNAME. Sets PREFIX to /var/www. Sets NO_TEST unless a do-test target is defined. Adds common dependencies to RUN_DEPENDS and BUILD_DEPENDS, sets MAKE_FILE and FAKE_FLAGS appropriately. Makes PEAR_LIBDIR and PEAR_PHPBIN available for use in the port. Sets a default PKGNAME and appends to CATEGORIES.
www/plone
Sets MODPLONE_VERSION and MODZOPE_VERSION. MODPLONE_VERSION is the default version used by all Plone ports and may be overridden. It appends www/plone to RUN_DEPENDS and also sets NO_TEST to Yes.
x11/gnome
This module has full support for the gnu, simple and cmake CONFIGURE_STYLE.

If both GNOME_PROJECT and GNOME_VERSION are set, this module defines DISTNAME, VERSION, MASTER_SITES, adds x11/gnome to CATEGORIES and EXTRACT_SUFX will default to .tar.xz if unset. Unless NO_BUILD=Yes, textproc/intltool is also appended to MODULES 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 nor AUTOMAKE_VERSION are defined, then "--disable-maintainer-mode" is appended to CONFIGURE_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" and LDFLAGS="-L${LOCALBASE}/lib" are always appended to CONFIGURE_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. If MODGNOME_TOOLS is set to desktop-file-utils, a dependency on devel/desktop-file-utils is appended to MODGNOME_RUN_DEPENDS and a link to /usr/bin/true is created under ${WRKDIR}/bin/desktop-file-validate. If MODGNOME_TOOLS is set to docbook, textproc/docbook-xsl is appended to MODGNOME_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. If MODGNOME_TOOLS is set to gtk-update-icon-cache, a dependency on x11/gtk+3,-guic is appended to MODGNOME_RUN_DEPENDS. If MODGNOME_TOOLS is set to shared-mime-info, a dependency on misc/shared-mime-info is appended to MODGNOME_RUN_DEPENDS and a link to /usr/bin/true is created under ${WRKDIR}/bin/update-mime-database. If MODGNOME_TOOLS is set to yelp, textproc/itstool and x11/gnome/doc-utils are appended to MODGNOME_BUILD_DEPENDS. Furthermore, x11/gnome/yelp is appended to MODGNOME_RUN_DEPENDS if MODGNOME_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 and MODGNOME_RUN_DEPENDS are appended to the corresponding BUILD_DEPENDS and RUN_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/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 under MODQT3_*, the qt4 module also defines the same variables under MODQT4_* and the qt5 module also defines the same variables under MODQT5_*, 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 and uic is available through MODQT*_LRELEASE, MODQT*_MOC, MODQT*_QMAKE and MODQT*_UIC. MODQT*_OVERRIDE_UIC controls whether the default setup will force a value of UIC or not. The value of MOC 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 of MODQT3_PLUGINS to correctly locate plugins.

The modules add to CONFIGURE_ENV, MAKE_ENV and MAKE_FLAGS. They define appropriate MODQT*_LIB_DEPENDS and MODQT*_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 set MODQT*_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 to LIB_DEPENDS, BUILD_DEPENDS or RUN_DEPENDS manually.

x11/tk
Sets MODTK_VERSION, MODTK_BIN, MODTK_INCDIR, MODTK_LIBDIR, MODTK_BUILD_DEPENDS, MODTK_RUN_DEPENDS, MODTK_LIB, MODTK_LIB_DEPENDS, and MODTK_CONFIG. MODTK_VERSION is the default version used by all Tk ports and may be overridden. Automatically adds the lang/tcl module, provides a default MODTCL_VERSION to match MODTK_VERSION, and affects CATEGORIES and SUBST_VARS. Note the MODTCL_WISH_ADJ shell fragment in the lang/tcl module.
x11/xfce4
Sets DIST_SUBDIR, EXTRACT_SUFX, CONFIGURE_STYLE, CONFIGURE_ENV and USE_GMAKE. If MODXFCE_ICON_CACHE is set to yes, it adds x11/gtk+3,-guic to RUN_DEPENDS. Unless XFCE_NO_SRC is set, textproc/intltool is added to MODULES. Also affects CATEGORIES.

Xfce ports can be divided into five categories: core libraries and applications, goodies, artwork, thunar plugins, and panel plugins. HOMEPAGE, MASTER_SITES and DISTNAME are built using XFCE_VERSION (which defaults to XFCE_DESKTOP_VERSION if not set) and either XFCE_PROJECT, XFCE_GOODIE, XFCE_ARTWORK, THUNAR_PLUGIN or XFCE_PLUGIN. One of the latter has to be provided by the port Makefile.

make(1), bsd.port.mk(5), ports(7)

September 15, 2020 OpenBSD-6.8