PORT-MODULES(5) | File Formats Manual | PORT-MODULES(5)

# 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/qt5 and x11/qt6. Instead of using the namespace `MODQT5*`, 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 `MODQT4_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/qt5 x11/qt6` and differentiate between qt5 and qt6 needs with `MODQT5_LIB_DEPENDS` and `MODQT6_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 defining `MODFOO_post-extract`. It will be run right after `post-extract`.
`patch`
  There is a `post-patch` hook that can be activated by defining `MODFOO_post-patch`. It will be run right after `post-patch`.
`gen`
  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.
`configure`
  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.

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

`install`
  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:

- Define a variable named `MODFOO_BUILD_TARGET` that contains the commands necessary for `do-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

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

# 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`, `MULTI_PACKAGES`, `NO_BUILD`, `NO_TEST`, `PATCH_LIST`, `PKG_ARCH`, `PKGNAME*`, `PREFIX`, `TEST_TARGET`, `TEST_IS_INTERACTIVE`, `REORDER_DEPENDENCIES`, `SEPARATE_BUILD`, `SITES`, `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.

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/cabal
  See cabal-module(5) for porting Haskell applications.
devel/cargo
  See cargo-module(5).
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/. PLIST must contain:

      @tag glib-compile-schemas

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

  To figure out some dependencies, meson(1) uses pkg-config(1) then falls back to cmake(1). As we do not want to enforce a dependency on devel/cmake/core, dpb(1) might junk it if it's found. This could create a race between finding foo.cmake and junking cmake(1) at configure time. To prevent this, unless devel/cmake/core is explicitly part of `BUILD_DEPENDS`, cmake(1) will be disabled by creating a link to false in ${WRKDIR}/bin/.

  This module supports 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/qmake
  See qmake-module(5).
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 `MODFONT_FAMILY` is set in combination with `MODFONT_VERSION`, it sets `PKGNAME`. `MODFONT_FAMILY` should be set to the name of the font family. This sets `MODFONT_FONTDIR` and `MODFONT_DOCDIR` using said family name. A `do-install` target is provided if the port itself does not provide it. This installs fonts from `WRKSRC` in the distribution. If one or more filenames (relative to `WRKSRC`) are listed in `MODFONT_FONTFILES`, they will be installed to `MODFONT_FONTDIR`. Otherwise, otf files in `WRKSRC` will be installed, with a fallback to ttf. If filenames (relative to `WRKSRC`) are listed in `MODFONT_DOCFILES`, they will be installed to `MODFONT_DOCDIR`.
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 gcc4 module. 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/go
  See go-module(5).
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/ocaml
  Appends to `BUILD_DEPENDS` and `MAKE_ENV`. Appends to `RUN_DEPENDS` unless `MODOCAML_RUNDEP` is set to No, or set to if-not-native and native compilation is supported on this architecture. Including this module 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` unless `MODPHP_RUNDEP` is set to No. Adds to `BUILD_DEPENDS` if `MODPHP_BUILDDEP` is set to Yes. 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 `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
  See python-module(5).
lang/ruby
  See ruby-module(5).
lang/rust
  Ports using Rust must use this module so a rebuild can be triggered via `SYSTEM_VERSION-rust` on updates of the lang/rust port or changes to the Rust standard library. Sets `MODRUST_WANTLIB` as appropriate for the architecture so it can be added to `WANTLIB`. It adds lang/rust to the `BUILD_DEPENDS` unless `MODRUST_BUILDDEP` is set to anything but “yes”.
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/mozilla
  Sets `PKGNAME`, `HOMEPAGE`, `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`.

wayland/wlroots
  Used for Wayland ports using the wlroots library. Sets `MODWLROOTS_LIB_DEPENDS`, `MODWLROOTS_WANTLIB` and `MODWLROOTS_VERSION`. Appends the corresponding values to `LIB_DEPENDS` and `WANTLIB`, unless `MODWLROOTS_LIBDEP` is set to No.
www/pear
  Used for PHP PEAR ports. Sets default `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`.
x11/gnome
  See gnome-module(5).
x11/gnustep
x11/qt5 and x11/qt6
  All qt* modules share a common `MODQT_*` namespace for simple ports. The qt5 module also defines the same variables under `MODQT5_*` and the qt6 module also defines the same variables under `MODQT6_*`, 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.

  The modules add to `CONFIGURE_ENV`, `MAKE_ENV` and `MAKE_FLAGS`. They define appropriate `MODQT*_LIB_DEPENDS` and `MODQT*_WANTLIB`.

  Note that Qt5 and Qt6 have their code split over several libraries. Both modules qt5 and qt6 doesn't set `MODQT*_WANTLIB` at all. Qt5 and Qt6 consist of many so called Qt modules, these 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+4,-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`, `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.

# SEE ALSO

make(1), bsd.port.mk(5), cabal-module(5), cargo-module(5), gnome-module(5), go-module(5), python-module(5), qmake-module(5), ruby-module(5), ports(7)

August 17, 2025 | Debian