PORT-MODULES(5)

📦 in nixpkgs unstable

🌸 port-modules 💅

okay so welcome to port-modules(5), straight out of the File Formats Manual section — this is the page that explains how the OpenBSD Ports framework splits itself up so it doesn't become one unhinged mega-file, and bestie, it's a lot, but we're gonna get through it together 🫶

✨ DESCRIPTION ✨

So the OpenBSD Ports framework is built on top of one absolutely gigantic makefile named bsd.port.mk(5). Like, gigantic gigantic. 💀

And to curb that unwieldy growth, the parts of the framework that aren't always needed got set apart into optional files called port modules, which get pulled in as needed through the MODULES variable of bsd.port.mk(5).

Some of these modules are just basic mechanisms that you don't always need — think GNU autoconf, or perl5.

And for convenience? Setting CONFIGURE_STYLE in a port's main Makefile is enough to get you perl5 or autoconf support. But lowkey the plot twist is: gnu, imake and perl5 are actually modules, and there's some glue in bsd.port.mk(5) that magically adds the required module in that case. ✨

⚠️ But that magic does not work when parsing modules. For instance, if you set CONFIGURE_STYLE=gnu in a module, you also need to MODULES += gnu. no cap, it will not do it for you.

Other modules are basically shortcuts for using some other ports as dependencies without needing to hardcode too much — the qt ports are the classic example.

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

So if the module is some/dir/portname, the ports framework will go looking for a file named ${PORTSDIR}/some/dir/portname/portname.port.mk and include it. that's the whole vibe check 💅

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 — so like, don't do that, bestie.

Modules may refer to each other, and the modules mechanism has specific recursion handling such that adding MODULES += foo/bar to a module will work as expected. 🌀

🏷️ NAMING CONVENTIONS 🏷️

Since there's no actual scope in makefiles, everything you define inside a module will be global to the ports framework — which means it may interfere with other ports. Yes, everything. It's giving "one big group chat, no private DMs." 😭

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 that aren't meant for user consumption should be named _MODFOO_* and _modfoo_*. (the leading underscore is the "do not perceive me" marker 🙈)

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.

And here's the 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 let ports override normal behavior. This evolved as an ad-hoc framework, where only hooks that turned out to be needed were added. And if several modules define the same hook, hook behaviors will be invoked in sequence. one after another, slay 💅

🧩 extract

There's a post-extract hook that can be activated by defining MODFOO_post-extract. It will be run right after post-extract.

🩹 patch

There's a post-patch hook that can be activated by defining MODFOO_post-patch. It will be run right after post-patch.

⚙️ gen

There's 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's 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 — it is the normal configure process. So if do-configure is overridden, normal hook processing will not happen. periodt.

🎭 fake

There's 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's 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:

  1. Define a variable named MODFOO_BUILD_TARGET that contains the commands necessary for do-build:
MODFOO_BUILD_TARGET = cmd1; cmd2
  1. 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, because 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. iconic behavior, honestly.

🧁 CORE MODULES DOCUMENTATION 🧁

The following modules are available.

📚 cpan

For perl ports coming from CPAN. It's a wrapper around the normal perl module that fetches the file from the correct location depending on DISTNAME, and sets a default PKGNAME. It also affects TEST_DEPENDS, CONFIGURE_STYLE, PKG_ARCH, and CATEGORIES.

Some CPAN modules are only indexed by author, so 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}

and that's the cpan module — but bestie we are so not done, there's more modules coming ✨

databases/mariadb 🐬

Okay bestie, this one's the whole framework for testing ports that need a running MariaDB. It defines MODMARIADB_TEST_TARGET, which is quite literally the actual commands that get run in the do-test target. If you didn't define that target yourself, don't worry — it gets added automatically. Slay.

Want to pick your own test command? Drop it in MODMARIADB_TEST_CMD. If you don't, the default is similar to what bsd.port.mk(5) runs itself. 💅

Here's the cute part: the MariaDB server that gets started listens on a UNIX domain socket only, so it barely touches your running system at all — minimizing impact, as the cool kids say. The path to that socket is recorded in MODMARIADB_TEST_SOCKET. And any local user can connect without a password. 🙈

  • If MODMARIADB_TEST_DBNAME is set, a database with that name gets set up before the actual test command runs.
  • Otherwise (that's the default), the test itself is responsible for calling mysqladmin(1) if it needs to. You're on your own, girl.

Heads up: databases/mariadb,-server gets added to TEST_DEPENDS, but not to any other *_DEPENDS. And MODMARIADB_CLIENT_ARGS and MODMARIADB_ADMIN_ARGS hold the arguments for mysql(1) and mysqladmin(1) respectively — use those arg lists in your test scripts to connect to the test server if the environment isn't giving you what you need. 🫶

databases/postgresql 🐘

Same energy, different database. This adds a small framework for testing ports that require a running Postgres. It defines MODPOSTGRESQL_TEST_TARGET, which holds the actual commands to run in the do-test target — and if that target isn't defined, it gets added automatically. Iconic.

  • MODPOSTGRESQL_TEST_CMD lets you specify the actual test command. Default is similar to what bsd.port.mk(5) runs itself.

The server that gets started listens on a UNIX domain socket only — again, minimal impact on your running system, love that for you. The directory where that socket gets created is set by MODPOSTGRESQL_TEST_PGHOST, which defaults to ${WRKDIR}. Any local user can connect without a password. 🔓

  • If MODPOSTGRESQL_TEST_DBNAME is set, a database with that name gets set up before the actual test command runs.
  • Otherwise (default), the test is responsible for calling initdb(1) itself. No hand-holding.

And databases/postgresql,-server gets added to TEST_DEPENDS, but not to any other *_DEPENDS. Periodt.

devel/cmake 🔧

Bestie, this is a big one. It adds devel/cmake to BUILD_DEPENDS and fills up CONFIGURE_ARGS, CONFIGURE_ENV and MAKE_ENV. It sets up the configure target. If CONFIGURE_STYLE wasn't set before, it sets it to cmake. It flips SEPARATE_BUILD to Yes by default because modern CMake requires out-of-source builds anyway (no cap). And it changes TEST_TARGET to test, since that's just the standard for CMake projects.

Also it's got knobs, and we love knobs:

  • MODCMAKE_DEBUG — if set to Yes, CMake produces a debug build instead of a release build. The exact effects on the build process depend on the settings in the CMake config files. Default is No.
  • MODCMAKE_LDFLAGS — if set, the value gets passed to CMake via the LDFLAGS environment variable during configuration. CMake only uses this on the first configuration, to set CMAKE_EXE_LINKER_FLAGS_INIT, CMAKE_SHARED_LINKER_FLAGS_INIT, and CMAKE_MODULE_LINKER_FLAGS_INIT. Default is empty.
  • MODCMAKE_VERBOSE — if set to Yes, CMake prints details during the configure and build stages about the exact command being run, etc. Should not be used in ports Makefiles. Default is Yes.
  • MODCMAKE_WANTCOLOR — if set to Yes, CMake colorizes its output. 🌈 Should not be used in ports Makefiles. Default is No.
  • USE_NINJA — if set to Yes, use ninja(1) as the build system instead of make(1), and add devel/ninja to BUILD_DEPENDS. If set to No, it uses the Unix Makefiles generator and adds 'nojunk' to DPB_PROPERTIES. Default is Yes.

✨ when it plays nice with other modules

When used together with other modules, the appropriate variables get passed to CMake automatically — it's giving teamwork:

  • java — JAVA_HOME is set in CONFIGURE_ENV and MAKE_ENV.
  • lang/python — the Python executable, library, and include paths are set for FindPython, FindPython3, and FindPythonN modules.
  • lang/lua — the Lua include directory and library path are set for FindLua.
  • lang/ruby — the Ruby executable is set for FindRuby.
  • lang/tcl — the Tcl version, include and library directories, and library name are set in CONFIGURE_ENV.
  • x11/tk — the Tk version, include and library directories, and library name are set in CONFIGURE_ENV.

Also: the environment variable MODCMAKE_PORT_BUILD is automatically set to yes in CONFIGURE_ENV and MAKE_ENV. What does that do? It disables CMake's default optimization flags (so ports stay in control of them) and prevents network operations (file DOWNLOAD/UPLOAD) during the build. Safety first, babe. 🛡️

devel/cabal 📦

Go read cabal-module(5) for porting Haskell applications. That's the whole entry, iykyk.

devel/cargo 🦀

See cargo-module(5). Short and sweet.

devel/dconf ⚙️

Sets CONFIGURE_ARGS, BUILD_DEPENDS and RUN_DEPENDS. This module is for ports installing gsettings schemas under ${PREFIX}/share/glib-2.0/schemas/. And your PLIST must contain this:

@tag glib-compile-schemas

No exceptions, bestie. 💖

devel/gconf2 🔗

So a link from gconftool-2(1) to true(1) gets put at the front of the PATH — sneaky but effective. It sets CONFIGURE_ARGS, BUILD_DEPENDS and RUN_DEPENDS. According to the values of MODGCONF2_LIBDEP, it also sets LIB_DEPENDS.

User settings: set MODGCONF2_SCHEMAS_DIR to the directory name under ${LOCALBASE}/share/schemas/ where the schemas files will be installed. 🌸

devel/meson 🛠️

Adds devel/meson and devel/ninja to BUILD_DEPENDS. Sets up the configure target. If CONFIGURE_STYLE wasn't set before, it sets it to meson. Flips SEPARATE_BUILD to Yes by default because meson requires out-of-source builds. And if CONFIGURE_STYLE is 'meson', then MODMESON_CONFIGURE_ARGS and MODMESON_CONFIGURE_ENV add their default values to CONFIGURE_ARGS and CONFIGURE_ENV.

Now, storytime: to figure out some dependencies, meson(1) uses pkg-config(1) and then falls back to cmake(1). But we do not want to force a dependency on devel/cmake/core, so dpb(1) might junk it if it finds it. That 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) gets disabled by creating a link to false in ${WRKDIR}/bin/. Problem solved, diva.

This module supports one knob:

  • MODMESON_WANTCOLOR — if set to Yes, meson colorizes its output. Should not be used in ports Makefiles. Default is No.

devel/qmake 🎨

See qmake-module(5). That's it, that's the entry.

devel/scons 🐍

Adds devel/scons to BUILD_DEPENDS. Sets MODSCONS_BIN and MODSCONS_ENV. It also defines an overridable MODSCONS_FLAGS. Then it provides do-build and do-install targets that you can override in the port Makefile. Chef's kiss. 👑

font 🔤

This one's for ports that primarily install fonts. It affects PKG_ARCH and EXTRACT_SUFX, and appends to CATEGORIES.

When MODFONT_FAMILY is set in combination with MODFONT_VERSION, it sets PKGNAME. Set MODFONT_FAMILY to the name of the font family — that's the whole point. It then sets MODFONT_FONTDIR, MODFONT_DOCDIR, and MODFONT_WEBDIR using said family name.

A do-install target is provided if the port itself doesn't provide one. This installs fonts from WRKSRC in the distribution. Here's the deets:

  • If one or more filenames (relative to WRKSRC) are listed in MODFONT_FONTFILES, they get installed to MODFONT_FONTDIR.
  • Otherwise, otf files in WRKSRC get installed, with a fallback to ttf.
  • If filenames (relative to WRKSRC) are listed in MODFONT_DOCFILES, they get installed to MODFONT_DOCDIR.
  • If filenames (relative to WRKSRC) are listed in MODFONT_WEBFILES, they get installed to MODFONT_WEBDIR. ⚠️ Ports that set MODFONT_WEBFILES must also declare a -web subpackage in MULTI_PACKAGES.

fortran 🧮

Sets MODFORTRAN_LIB_DEPENDS, MODFORTRAN_WANTLIB, and MODFORTRAN_BUILD_DEPENDS. Set MODFORTRAN_COMPILER to gfortran or flang, depending on what your port requires — default is gfortran. The dependencies get chosen according to whatever MODFORTRAN_COMPILER is set to. Simple as that. ✨

gcc4 🏗️

If COMPILER_VERSION is not gcc4 (that's defined by /usr/share/mk/bsd.own.mk), and the architecture is in MODGCC4_ARCHS, then the gcc4 compilers get put at the front of the path.

By default, only C language support comes with this module. Need other languages? List them in MODGCC4_LANGS (e.g. c++, fortran). The MODGCC4_VERSION variable changes the version of gcc — default is gcc 4.9. And 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. Go check it out there, bestie.

  • imake — honestly this one's just a vibe, the real tea is in the main bsd.port.mk(5) manpage 📖
  • java — okay so set MODJAVA_VER=x.y if you want exactly JDK x.y, or MODJAVA_VER=x.y+ if any x.y-or-newer version is fine 🫶. And set MODJAVA_JRERUN=Yes when the port only needs the JRE at runtime.

This 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, plus a do-build target (only if one isn't already defined, bestie). It heeds NO_BUILD.

  • lang/clang — similar to the gcc4 module. If the architecture is in MODCLANG_ARCHS, the Clang compilers get put at the front of the path ✨. By default only C language support is included by this module — if you need other languages they must be listed in MODCLANG_LANGS (e.g. c++). Sets MODCLANG_VERSION which is also appended to SUBST_VARS.
  • lang/erlang — no extra lore here 💅
  • lang/go — see go-module(5) 👀
  • lang/lua — this one 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. It 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. Then it 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 FULLPKGNAME is adjusted, if MODLUA_SA is not set. In order to set a build, run or test dependency on a lua port, use MODLUA_BUILD_DEPENDS, MODLUA_TEST_DEPENDS, MODLUA_RUN_DEPENDS — these propagate the currently used flavor 🧚

  • 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. Chef's kiss choice logic 🎀

  • 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_DEPENDS, and MODTCL_LIB. 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.
  • perl — 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 — no extra lore here either 🙈
  • 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. Take the hint, bestie 🫶

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 — okay so this one sets MODTK_VERSION, MODTK_BIN, MODTK_INCDIR, MODTK_LIBDIR, MODTK_BUILD_DEPENDS, MODTK_RUN_DEPENDS, MODTK_LIB_DEPENDS, and MODTK_LIB. MODTK_VERSION is the default version that all Tk ports use, and bestie you can override it. It automatically adds the lang/tcl module, hands you a default MODTCL_VERSION that matches MODTK_VERSION, and it affects CATEGORIES. Also clock the MODTCL_WISH_ADJ shell fragment in the lang/tcl module — iykyk 💅.
  • 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 gets added to MODULES. It 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 it's not set) and either XFCE_PROJECT, XFCE_GOODIE, XFCE_ARTWORK, THUNAR_PLUGIN, or XFCE_PLUGIN. One of the latter — XFCE_PROJECT, XFCE_GOODIE, XFCE_ARTWORK, THUNAR_PLUGIN, or XFCE_PLUGIN — has to be provided by the port Makefile. fr fr, don't forget it 🫶.

🌈 SEE ALSO 🌈

mwah 💋 that's the whole page, bestie! source: Debian, date: March 16, 2026, manual page: PORT-MODULES(5) ✨🎀

📦 where this page comes from