OpenBSD manual page server

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

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:

and provide a module-specific variable with the same value:

The following variables can be overridden in a relatively safe fashion: ALL_TARGET, CONFIGURE_SCRIPT, DESTDIRNAME, DIST_SUBDIR, DISTNAME, DISTFILES, EXTRACT_SUFX, FAKE_FLAGS, FETCH_MANUALLY, HOMEPAGE, IGNORE, IS_INTERACTIVE, LIBTOOL_FLAGS, MAKE_FILE, MASTER_SITES, MULTI_PACKAGES, NO_BUILD, NO_TEST, PATCH_LIST, PKG_ARCH, PKGNAME*, PREFIX, TEST_TARGET, TEST_IS_INTERACTIVE, REORDER_DEPENDENCIES, SEPARATE_BUILD, USE_GMAKE, USE_LIBTOOL.

The following variables can be added to in a relatively safe fashion: BUILD_DEPENDS, CATEGORIES, CONFIGURE_ARGS, CONFIGURE_ENV, ERRORS, FAKE_FLAGS, FLAVOR, FLAVORS, INSTALL_TARGET, LIB_DEPENDS, MAKE_ENV, MAKE_FLAGS, PKG_ARGS, PSEUDO_FLAVORS, TEST_DEPENDS, REORDER_DEPENDENCIES, RUN_DEPENDS, SUBST_VARS, WANTLIB.

SPECIFIC MODULE INTERACTIONS

Some modules correspond to extra ports that will be used mostly as BUILD_DEPENDS or RUN_DEPENDS. Such modules can safely append values directly to the BUILD_DEPENDS, RUN_DEPENDS, LIB_DEPENDS, and WANTLIB variables, as long as they also define module-specific variables for all runtime dependencies.

Simple client ports will use the module directly, and thus inherit extra build and runtime dependencies.

More sophisticated ports can use MULTI_PACKAGES to select specific behavior: build-time dependencies will always be needed. Runtime dependencies will be selected on a subpackage basis, since runtime dependencies such as LIB_DEPENDS-sub do not inherit the default LIB_DEPENDS value. The client port's author must only bear in mind that external modules may add values to the default WANTLIB, LIB_DEPENDS, and RUN_DEPENDS, and thus that it is not safe to inherit from it blindly.

Modules are imported during

Thus they can be affected by user choices such as setting a variable to Yes or No. Modules may make decisions based on documented MODFOO_BEHAVIOR values.

When modules are processed, only a few bsd.port.mk(5) variables are already defined. Modules may depend upon the following variables already having a sane value: DISTDIR, LOCALBASE, NO_DEPENDS, PKGPATH, PORTSDIR, X11BASE and all arch-dependent constants from bsd.port.arch.mk(5), such as PROPERTIES or LP64_ARCHS. Note that this is only relevant for tests. It is perfectly okay to define variables or targets that depend on the basic ports framework without having to care whether that variable is already defined, since make(1) performs lazy evaluation.

CORE MODULES DOCUMENTATION

The following modules are available.

apache-module

 

cpan

For perl ports coming from CPAN. Wrapper around the normal perl module that fetches the file from the correct location depending on DISTNAME, and sets a 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/. 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/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 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 extensions 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/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 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

See python-module(5).

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

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

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)