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 definingMODFOO_post-extract
. It will be run right afterpost-extract
. patch
- There is a
post-patch
hook that can be activated by definingMODFOO_post-patch
. It will be run right afterpost-patch
. gen
- There is a
gen
hook that can be activated by definingMODFOO_gen
. It will be run right afterdo-gen
and beforeREORDER_DEPENDENCIES
touches things. configure
- There is a
pre-configure
hook that can be activated by definingMODFOO_pre-configure
. It will be run right afterpre-configure
. The normaldo-configure
behavior is to invoke allMODFOO_configure
contents that are defined inCONFIGURE_STYLE
. By default,configure
will do nothing.Some
CONFIGURE_STYLE
values, namely perl, gnu, imake, and autoconf, will automatically import the correct module. User-defined modules must both add toCONFIGURE_STYLE
and import the correct module to override behavior.Contrary to other hooks, module behavior is not invoked in addition to
do-configure
, but as the normal configure process. Ifdo-configure
is overridden, normal hook processing will not happen. fake
- There is a
pre-fake
hook that can be activated by definingMODFOO_pre-fake
. This will be invoked right after mtree(8), and before the normalpre-fake
behavior.This can occasionally be used for ports that require some specific fake installation setup that will be provided by runtime dependencies.
install
- There is a
post-install
hook that can be activated by definingMODFOO_post-install
. This will be invoked at the end ofinstall
, right after the normalpost-install
behavior.
Some targets, such as do-build
or
do-install
, can't be overridden simply. A module
that, for instance, requires specific do-build
behavior should do so in two steps:
- Define a variable named
MODFOO_BUILD_TARGET
that contains the commands necessary fordo-build
:MODFOO_BUILD_TARGET = cmd1; cmd2
- Override
do-build
only if it's not already defined by the port proper:.if !target(do-build) do-build: @${MODFOO_BUILD_TARGET} .endif
do-build: @${MODBAR_BUILD_TARGET} @${MODFOO_BUILD_TARGET} ...
OVERRIDING VARIABLE BEHAVIOR
Some variables can be overridden by modules. Be very cautious, as this can make the module difficult to use, or interact badly with other modules. As a rule, always provide the override as:
VARIABLE ?= value
and provide a module-specific variable with the same value:
MODFOO_VARIABLE = value
The following variables can be overridden in a relatively safe
fashion: ALL_TARGET
,
CONFIGURE_SCRIPT
,
DESTDIRNAME
, DIST_SUBDIR
,
DISTNAME
, DISTFILES
,
EXTRACT_SUFX
, FAKE_FLAGS
,
FETCH_MANUALLY
, HOMEPAGE
,
IGNORE
, IS_INTERACTIVE
,
LIBTOOL_FLAGS
, MAKE_FILE
,
MASTER_SITES
,
MULTI_PACKAGES
, NO_BUILD
,
NO_TEST
, PATCH_LIST
,
PKG_ARCH
, PKGNAME*
,
PREFIX
, TEST_TARGET
,
TEST_IS_INTERACTIVE
,
REORDER_DEPENDENCIES
,
SEPARATE_BUILD
, USE_GMAKE
,
USE_LIBTOOL
.
The following variables can be added to in a relatively safe
fashion: BUILD_DEPENDS
,
CATEGORIES
, CONFIGURE_ARGS
,
CONFIGURE_ENV
, ERRORS
,
FAKE_FLAGS
, FLAVOR
,
FLAVORS
, INSTALL_TARGET
,
LIB_DEPENDS
, MAKE_ENV
,
MAKE_FLAGS
, PKG_ARGS
,
PSEUDO_FLAVORS
,
TEST_DEPENDS
,
REORDER_DEPENDENCIES
,
RUN_DEPENDS
, SUBST_VARS
,
WANTLIB
.
SPECIFIC MODULE INTERACTIONS
Some modules correspond to extra ports that will be used mostly as
BUILD_DEPENDS
or
RUN_DEPENDS
. Such modules can safely append values
directly to the BUILD_DEPENDS
,
RUN_DEPENDS
, LIB_DEPENDS
,
and WANTLIB
variables, as long as they also define
module-specific variables for all runtime dependencies.
Simple client ports will use the module directly, and thus inherit extra build and runtime dependencies.
More sophisticated ports can use
MULTI_PACKAGES
to select specific behavior:
build-time dependencies will always be needed. Runtime dependencies will be
selected on a subpackage basis, since runtime dependencies such as
LIB_DEPENDS-sub
do not inherit the default
LIB_DEPENDS
value. The client port's author must
only bear in mind that external modules may add values to the default
WANTLIB
, LIB_DEPENDS
, and
RUN_DEPENDS
, and thus that it is not safe to inherit
from it blindly.
Modules are imported during
.include
<bsd.port.mk>
Thus they can be affected by user choices such as setting a
variable to Yes or No. Modules may make decisions based on documented
MODFOO_BEHAVIOR
values.
When modules are processed, only a few
bsd.port.mk(5) variables are already defined. Modules may
depend upon the following variables already having a sane value:
DISTDIR
, LOCALBASE
,
NO_DEPENDS
, PKGPATH
,
PORTSDIR
, X11BASE
and all
arch-dependent constants from
bsd.port.arch.mk(5), such as
PROPERTIES
or LP64_ARCHS
.
Note that this is only relevant for tests. It is perfectly okay to define
variables or targets that depend on the basic ports framework without having
to care whether that variable is already defined, since
make(1) performs lazy evaluation.
CORE MODULES DOCUMENTATION
The following modules are available.
- apache-module
- cpan
- For perl ports coming from CPAN. Wrapper around the normal perl module
that fetches the file from the correct location depending on
DISTNAME
, and sets a defaultPKGNAME
. Also affectsTEST_DEPENDS
,CONFIGURE_STYLE
,PKG_ARCH
, andCATEGORIES
.Some CPAN modules are only indexed by author, set
CPAN_AUTHOR=ID
to locate the right directory.If no
HOMEPAGE
is defined, it will default to http://search.cpan.org/dist/${DISTNAME:C/-[^-]*$//}/User settings: set
CPAN_REPORT
to Yes,CPAN_REPORT_DB
to a valid directory, andCPAN_REPORT_FROM
to a valid email address to automate the reporting of regression tests to CPAN.If
MODCPAN_EXAMPLES
is set, the following variables will be set.MODCPAN_EXAMPLES_DIST
will hold the default directory in the distfile with example scripts.MODCPAN_EXAMPLES_DIR
will be set to the standard installation directory for examples. Sets thepost-install
target if none has been defined to install the examples, otherwiseMODCPAN_POST_INSTALL
should be used as such:post-install: ... ${MODCPAN_POST_INSTALL}
- databases/mariadb
- Adds small framework for testing ports that require running MariaDB.
Defines
MODMARIADB_TEST_TARGET
which consists actual commands to run indo-test
target. If this target isn't defined, it will be added automatically.The actual test command to be run could be specified in the
MODMARIADB_TEST_CMD
. Default is similar to what bsd.port.mk(5) runs itself.The MariaDB server being started will listen on UNIX domain socket only, minimizing impact on running system. The path to socket is recorded in
MODMARIADB_TEST_SOCKET
. Any local user will be able to connect without password.If the
MODMARIADB_TEST_DBNAME
variable is set, the database with such name will be set up before running actual test command. Otherwise (default), the test is responsible to call mysqladmin(1) itself, if needed.The databases/mariadb,-server will get added to
TEST_DEPENDS
, but not to any other*_DEPENDS
. TheMODMARIADB_CLIENT_ARGS
andMODMARIADB_ADMIN_ARGS
variables hold arguments for mysql(1) and mysqladmin(1), respectively; those argument lists could be used in test scripts for connecting to test server, if they aren't satisfied by environment. - databases/postgresql
- Adds small framework for testing ports that require running Postgres.
Defines
MODPOSTGRESQL_TEST_TARGET
which consists actual commands to run indo-test
target. If this target isn't defined, it will be added automatically.The actual test command to be run could be specified in the
MODPOSTGRESQL_TEST_CMD
. Default is similar to what bsd.port.mk(5) runs itself.The Postgres server being started will listen on UNIX domain socket only, minimizing impact on running system. The path to directory where socket will be created is set by
MODPOSTGRESQL_TEST_PGHOST
, defaulting to ${WRKDIR}. Any local user will be able to connect without password.If the
MODPOSTGRESQL_TEST_DBNAME
variable is set, the database with such name will be set up before running actual test command. Otherwise (default), the test is responsible to call initdb(1) itself.The databases/postgresql,-server will get added to
TEST_DEPENDS
, but not to any other*_DEPENDS
. - devel/cmake
- Adds devel/cmake to
BUILD_DEPENDS
and fills upCONFIGURE_ARGS
,CONFIGURE_ENV
andMAKE_ENV
. Sets upconfigure
target. IfCONFIGURE_STYLE
was not set before, sets its value to `cmake'. Changes default value ofSEPARATE_BUILD
to `Yes' because modern CMake requires out-of-source build anyway. ChangesTEST_TARGET
to `test' as this is standard for CMake projects. Also this module has the following knobs:- MODCMAKE_WANTCOLOR
- If set to `Yes', CMake will colorize its output. Should not be used in ports Makefiles. Default value is `No'.
- MODCMAKE_VERBOSE
- If set to `Yes', CMake will print details during configure and build stages about exact command being run, etc. Should not be used in ports Makefiles. Default value is `Yes'.
- MODCMAKE_DEBUG
- If set to `Yes', CMake will produce a debug build instead of a release build. The exact effects on the build process depend on settings specified in the CMake config files. Default value is `No'.
- devel/cabal
- See cabal-module(5) for porting Haskell applications.
- devel/cargo
- See cargo-module(5).
- devel/dconf
- Sets
CONFIGURE_ARGS
,BUILD_DEPENDS
andRUN_DEPENDS
. This module is used by ports installing gsettings schemas under ${PREFIX}/share/glib-2.0/schemas/. It requires the following goo in the PLIST:@exec %D/bin/glib-compile-schemas %D/share/glib-2.0/schemas >/dev/null @unexec-delete %D/bin/glib-compile-schemas %D/share/glib-2.0/schemas >/dev/null
- devel/gconf2
- A link from
gconftool-2(1) to
true(1) will be put at the front of the
PATH
. SetsCONFIGURE_ARGS
,BUILD_DEPENDS
andRUN_DEPENDS
. According to the values ofMODGCONF2_LIBDEP
, setsLIB_DEPENDS
. User settings: setMODGCONF2_SCHEMAS_DIR
to the directory name under ${LOCALBASE}/share/schemas/ where schemas files will be installed. - devel/meson
- Adds devel/meson and
devel/ninja to
BUILD_DEPENDS
. Sets upconfigure
target. IfCONFIGURE_STYLE
was not set before, sets its value to `meson'. Changes default value ofSEPARATE_BUILD
to `Yes' because meson requires out-of-source build. IfCONFIGURE_STYLE
is 'meson',MODMESON_CONFIGURE_ARGS
andMODMESON_CONFIGURE_ENV
will add default values toCONFIGURE_ARGS
andCONFIGURE_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
. SetsMODSCONS_BIN
andMODSCONS_ENV
. Also defines an overridableMODSCONS_FLAGS
. It provides ado-build
anddo-install
targets that can be overridden in the port Makefile. - font
- Used for ports which primarily install fonts. Affects
PKG_ARCH
andEXTRACT_SUFX
. Appends toCATEGORIES
. WhenTYPEFACE
is set in combination withV
orVERSION
, it setsPKGNAME
.TYPEFACE
should be set to the name of the typeface. This setsFONTDIR
using said typeface name. Ado-install
target is provided if the port itself does not provide it. This installs fonts fromWRKSRC
in the distribution. If one or more file extensions are listed inFONTTYPES
, files of those types will be used. Otherwise, otf files are preferred, with a fallback to ttf. - fortran
- Sets
MODFORTRAN_LIB_DEPENDS
,MODFORTRAN_WANTLIB
,MODFORTRAN_BUILD_DEPENDS
. SetMODFORTRAN_COMPILER
to `gfortran', or `flang', depending on what the port requires. The default is `gfortran'. The dependencies are chosen according toMODFORTRAN_COMPILER
. - gcc4
- If
COMPILER_VERSION
is not gcc4 (defined by /usr/share/mk/bsd.own.mk), and architecture is inMODGCC4_ARCHS
, then the gcc4 compilers will be put at the front of the path. By default, only C language support is included by this module. If other languages are needed, they must be listed inMODGCC4_LANGS
(e.g. c++, fortran). TheMODGCC4_VERSION
variable can be used to change the version of gcc. By default gcc 4.9 is used. IfMODGCC4_LANGS
contains c++, this module providesMODGCC4_CPPLIBDEP
andMODGCC4_CPPWANTLIB
. - gnu
- This module is documented in the main bsd.port.mk(5) manpage.
- imake
- This module is documented in the main bsd.port.mk(5) manpage.
- java
- Set
MODJAVA_VER=x.y
to use exactly the JDK x.y,MODJAVA_VER=x.y+
to use any x.y or higher version. SetMODJAVA_JRERUN=Yes
if the port only needs the JRE at runtime. The module setsJAVA_HOME
,ONLY_FOR_ARCHS
,MODJAVA_RUN_DEPENDS
,MODJAVA_SHARE_DIR
,MODJAVA_JAR_DIR
,MODJAVA_EXAMPLE_DIR
andMODJAVA_DOC_DIR
. It appends toBUILD_DEPENDS
,RUN_DEPENDS
,CATEGORIES
andSUBST_VARS
. IfMODJAVA_BUILD=ant
then this module providesMODJAVA_BUILD_DIR
,MODJAVA_BUILD_FILE
andMODJAVA_BUILD_TARGET_NAME
, as well as ado-build
target (if not already defined). It heedsNO_BUILD
. - lang/clang
- Similar to 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++). SetsMODCLANG_VERSION
which is also appended toSUBST_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 toCATEGORIES
. Also appends toBUILD_DEPENDS
, unlessNO_BUILD
has been set to Yes. Also appends toRUN_DEPENDS
, unlessMODLUA_RUNDEP
is set to No. AppendsMODLUA_VERSION
,MODLUA_LIB
,MODLUA_INCL_DIR
,MODLUA_EXAMPLEDIR
,MODLUA_DOCDIR
,MODLUA_LIBDIR
,MODLUA_DATADIR
,MODLUA_DEP
,MODLUA_DEP_VERSION
,MODLUA_BIN
toSUBST_VARS
.MODLUA_DEFAULT_VERSION
is set to 5.1.MODLUA_VERSION is set to
MODLUA_DEFAULT_VERSION
by default. Ports can be built with several lua versions. If no FLAVOR is set, it defaults to MODLUA_DEFAULT_VERSION. Otherwise the FULLPKGNAME is adjusted, if MODLUA_SA is not set. In order to set a build, run or test dependency on a lua port, use the following, which will propagate the currently used flavor:MODLUA_BUILD_DEPENDS
,MODLUA_TEST_DEPENDS
,MODLUA_RUN_DEPENDS
. - lang/mono
- Sets
MODMONO_ONLY_FOR_ARCHS
,CONFIGURE_ENV
,MAKE_FLAGS
,MODMONO_BUILD_DEPENDS
andMODMONO_RUN_DEPENDS
. IfMODMONO_DEPS
is set to Yes, lang/mono is appended toBUILD_DEPENDS
andRUN_DEPENDS
.DLLMAP_FILES
defines in which files the module will substitute hardcoded shared library versions using apost-configure
target. - lang/ocaml
- Appends to
BUILD_DEPENDS
andMAKE_ENV
. Appends toRUN_DEPENDS
unlessMODOCAML_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 andocaml_native
property depending on whether the architecture supports native compilation. If dynamic linking is supported on the native architecture, the %%dynlink%% plist fragment andocaml_native_dynlink
property is set. WhenCONFIGURE_STYLE
is set to `oasis', overrides for thedo-build
,do-install
, anddo-test
targets are added. - lang/php
- Used for ports using PHP in some way: either extensions to PHP, or
software written in PHP. Sets
MODPHP_RUN_DEPENDS
,MODPHP_LIB_DEPENDS
,MODPHP_WANTLIB
,MODPHP_BIN
,MODPHP_PHPIZE
,MODPHP_PHP_CONFIG
,MODPHP_INCDIR
andMODPHP_LIBDIR
. Adds toRUN_DEPENDS
unlessMODPHP_RUNDEP
is set to No. Adds toBUILD_DEPENDS
ifMODPHP_BUILDDEP
is set to Yes. IfMODPHP_DO_PHPIZE
is set, prepares a build environment for extensions that use phpize.Ports using PDO for database connectivity often have a choice of dependencies (pdo_sqlite, pdo_mysql, pdo_pgsql and others). The module constructs
MODPHP_PDO_DEPENDS
from the PDO types listed inMODPHP_PDO_ALLOWED
(defaulting to "sqlite mysql pgsql"). This can be added toRUN_DEPENDS
and allows any of these PDO packages to satisfy the dependency, withMODPHP_PDO_PREF
(sqlite by default) chosen if none are installed. - lang/php/pecl
- Used for ports for PHP PECL extensions. Sets default
MASTER_SITES
,HOMEPAGE
,EXTRACT_SUFX
,DESTDIRNAME
,MODPHP_DO_SAMPLE
,MODPHP_DO_PHPIZE
,AUTOCONF_VERSION
,AUTOMAKE_VERSION
,LIBTOOL_FLAGS
. Provides a defaultTEST_TARGET
andTEST_FLAGS
unlessNO_TEST
or ado-test
target is defined. Adds common dependencies toRUN_DEPENDS
andBUILD_DEPENDS
. Sets a defaultPKGNAME
and appends toCATEGORIES
. - lang/python
- 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
, andMODTCL_CONFIG
.MODTCL_VERSION
is the default version used by all Tcl ports and may be overridden. ProvidesMODTCL_TCLSH_ADJ
andMODTCL_WISH_ADJ
shell fragments to patch the interpreter path in executable scripts. Also affectsCATEGORIES
andSUBST_VARS
. - perl
- This module is documented in the main bsd.port.mk(5) manpage.
- security/heimdal
- A link from ${LOCALBASE}/heimdal/bin/krb5-config to
krb5-config(1) will be put at the front of the path. Sets
LIB_DEPENDS
andWANTLIB
according to the values ofMODHEIMDAL_LIB_DEPENDS
, andMODHEIMDAL_WANTLIB
. - textproc/intltool
- Sets
MODINTLTOOL_OVERRIDE
. textproc/intltool is added toBUILD_DEPENDS
.MODINTLTOOL_OVERRIDE
changes the paths ofINTLTOOL_EXTRACT
,INTLTOOL_MERGE
andINTLTOOL_UPDATE
to use the installed versions of intltool-extract, intltool-merge and intltool-update, instead of the version's packages into the distfile of the port using this module. Also affectsCONFIGURE_ENV
,MAKE_ENV
andMAKE_FLAGS
by appendingMODINTLTOOL_OVERRIDE
to them. - www/mozilla
- Sets
PKGNAME
,HOMEPAGE
,MASTER_SITES
,DISTNAME
,USE_GMAKE
, andONLY_FOR_ARCHS
.EXTRACT_SUFX
defaults to .tar.bz2.Adds common dependencies to
LIB_DEPENDS
,WANTLIB
,RUN_DEPENDS
andBUILD_DEPENDS
. Sets commonCONFIGURE_ARGS
,MAKE_ENV
andCONFIGURE_ENV
. SetsMOB
variable as source directory andMOZ
as target directory withindo-install
.Individual port Makefile must set
MOZILLA_PROJECT
,MOZILLA_CODENAME
,MOZILLA_VERSION
,MOZILLA_BRANCH
,MOZILLA_LIBS
andMOZILLA_DATADIRS
variables. Port can also append values toMOZILLA_SUBST_FILES
which contains the list of files to runSUBST_CMD
on duringpre-configure
, andMOZILLA_AUTOCONF_DIRS
which contains the list of dirs whereAUTOCONF
will be run duringpre-configure
. - www/pear
- Used for PHP PEAR ports. Sets default
MASTER_SITES
,EXTRACT_SUFX
,PKGNAME
. SetsPREFIX
to /var/www. SetsNO_TEST
unless ado-test
target is defined. Adds common dependencies toRUN_DEPENDS
andBUILD_DEPENDS
, setsMAKE_FILE
andFAKE_FLAGS
appropriately. MakesPEAR_LIBDIR
andPEAR_PHPBIN
available for use in the port. Sets a defaultPKGNAME
and appends toCATEGORIES
. - 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 underMODQT5_*
and the qt6 module also defines the same variables underMODQT6_*
, to allow ports to use both modules, such as print/poppler.Those modules define
MODQT*_LIBDIR
as the libraries location,MODQT*_INCDIR
as the include files location,MODQT*_QTDIR
as the global qt directory location,MODQT*_CONFIGURE_ARGS
as standard GNU configure-style parameters to locate the include and libraries.The location of Qt-specific tools
lrelease
,moc
,qmake
anduic
is available throughMODQT*_LRELEASE
,MODQT*_MOC
,MODQT*_QMAKE
andMODQT*_UIC
.MODQT*_OVERRIDE_UIC
controls whether the default setup will force a value ofUIC
or not. The value ofMOC
is always forced to ${MODQT*_MOC}.In most cases the devel/qmake module should be used instead of using
MODQT*_QMAKE
directly.The modules add to
CONFIGURE_ENV
,MAKE_ENV
andMAKE_FLAGS
. They define appropriateMODQT*_LIB_DEPENDS
andMODQT*_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 toLIB_DEPENDS
,BUILD_DEPENDS
orRUN_DEPENDS
manually. - x11/tk
- Sets
MODTK_VERSION
,MODTK_BIN
,MODTK_INCDIR
,MODTK_LIBDIR
,MODTK_BUILD_DEPENDS
,MODTK_RUN_DEPENDS
,MODTK_LIB
,MODTK_LIB_DEPENDS
, andMODTK_CONFIG
.MODTK_VERSION
is the default version used by all Tk ports and may be overridden. Automatically adds the lang/tcl module, provides a defaultMODTCL_VERSION
to matchMODTK_VERSION
, and affectsCATEGORIES
andSUBST_VARS
. Note theMODTCL_WISH_ADJ
shell fragment in the lang/tcl module. - x11/xfce4
- Sets
DIST_SUBDIR
,EXTRACT_SUFX
,CONFIGURE_STYLE
,CONFIGURE_ENV
andUSE_GMAKE
. IfMODXFCE_ICON_CACHE
is set to yes, it adds x11/gtk+4,-guic toRUN_DEPENDS
. UnlessXFCE_NO_SRC
is set, textproc/intltool is added toMODULES
. Also affectsCATEGORIES
.Xfce ports can be divided into five categories: core libraries and applications, goodies, artwork, thunar plugins, and panel plugins.
HOMEPAGE
,MASTER_SITES
andDISTNAME
are built usingXFCE_VERSION
(which defaults toXFCE_DESKTOP_VERSION
if not set) and eitherXFCE_PROJECT
,XFCE_GOODIE
,XFCE_ARTWORK
,THUNAR_PLUGIN
orXFCE_PLUGIN
. One of the latter has to be provided by the port Makefile.
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)