PORT-MODULES(5) | File Formats Manual | PORT-MODULES(5) |
port-modules
—
documentation and conventions used in port
modules
The OpenBSD Ports framework is based on a gigantic makefile named bsd.port.mk(5).
In order to curb unwieldy growth, parts of the framework that are
not always needed have been set apart in optional files called
port modules
, which are retrieved as needed through
the MODULES
variable of
bsd.port.mk(5).
Some of these modules correspond to basic mechanisms which are not always needed, such as GNU autoconf, or perl5.
For convenience, setting CONFIGURE_STYLE
in a port's main Makefile is enough to get perl5 or autoconf support, but
gnu, imake and
perl5 are actually modules, and there is some glue in
bsd.port.mk(5) that
magically adds the required module in that case. This doesn't work when
parsing modules. For instance, if you set
CONFIGURE_STYLE=gnu
in a module, you also need to
MODULES += gnu
.
Other modules correspond to shortcuts for using some other ports as dependencies without needing to hardcode too much, such as the qt ports.
The variable MODULES
should contain a list
of module names. Some core modules are a single word, all other modules
should be ${PKGPATH}. If the module is
some/dir/portname, the ports framework will look for
a file named
${PORTSDIR}/some/dir/portname/portname.port.mk and
include it.
Most modules should conform to this syntax. The historic practice of having a redirection file directly under ${PORTSDIR}/infrastructure/mk is deprecated for new modules.
Modules may refer to each other. The modules mechanism has
specific recursion handling such that adding MODULES +=
foo/bar
to a module will work as expected.
Since there is no actual scope in makefiles, everything defined within a module will be global to the ports framework, and thus may interfere with other ports.
As far as possible, all variables and targets belonging to a
module named some/dir/foo should be named
MODFOO_*
and modfoo_*.
Following the same conventions as
bsd.port.mk(5), internal
variables and targets not intended for user consumption should be named
_MODFOO_*
and _modfoo_*.
For instance, if a module wants some value to be available for the
rest of the world, it should define MODFOO_VARNAME
,
with a name matching the basic infrastructure as far as possible. That is, a
port that defines specific dependencies will usually define
MODFOO_WANTLIB
,
MODFOO_LIB_DEPENDS
, and
MODFOO_RUN_DEPENDS
, as appropriate.
As an exception to the naming mechanism, some ports have several
distinct versions in the ports tree, say x11/qt3 and
x11/qt4. Instead of using the namespace
MODQT3*
, variables will usually drop the version
suffix and be simply called MODQT_*
so that a port
using the module can be switched from version to version without needing to
change everything.
It is highly desirable to define names in both namespaces for such
ports, for example to define both MODQT3_LIB_DEPENDS
and MODQT_LIB_DEPENDS
. Normal client ports will use
MODQT_LIB_DEPENDS
, but a port may exceptionally
import both modules with MODULES += x11/qt3 x11/qt4
and differentiate between qt3 and qt4 needs with
MODQT3_LIB_DEPENDS
and
MODQT4_LIB_DEPENDS
. See
print/poppler for an example.
The main framework contains several hooks that allow ports to override normal behavior. This evolved as an ad-hoc framework, where only hooks that turned out to be needed were added. If several modules define the same hook, hook behaviors will be invoked in sequence.
extract
post-extract
hook that can be activated
by defining MODFOO_post-extract
. It will be run
right after post-extract
.patch
post-patch
hook that can be activated
by defining MODFOO_post-patch
. It will be run
right after post-patch
.gen
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
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
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
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:
MODFOO_BUILD_TARGET
that
contains the commands necessary for do-build
:
MODFOO_BUILD_TARGET = cmd1; cmd2
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} ...
Some variables can be overridden by modules. Be very cautious, as this can make the module difficult to use, or interact badly with other modules. As a rule, always provide the override as:
VARIABLE ?= value
and provide a module-specific variable with the same value:
MODFOO_VARIABLE = value
The following variables can be overridden in a relatively safe
fashion: ALL_TARGET
,
CONFIGURE_SCRIPT
,
DESTDIRNAME
, DIST_SUBDIR
,
DISTNAME
, DISTFILES
,
EXTRACT_SUFX
, FAKE_FLAGS
,
FETCH_MANUALLY
, HOMEPAGE
,
IGNORE
, IS_INTERACTIVE
,
LIBTOOL_FLAGS
, MAKE_FILE
,
MASTER_SITES
,
MULTI_PACKAGES
, NO_BUILD
,
NO_TEST
, PATCH_LIST
,
PKG_ARCH
, PKGNAME*
,
PREFIX
, TEST_TARGET
,
TEST_IS_INTERACTIVE
,
REORDER_DEPENDENCIES
,
SEPARATE_BUILD
, USE_GMAKE
,
USE_LIBTOOL
.
The following variables can be added to in a relatively safe
fashion: BUILD_DEPENDS
,
CATEGORIES
, CONFIGURE_ARGS
,
CONFIGURE_ENV
, ERRORS
,
FAKE_FLAGS
, FLAVOR
,
FLAVORS
, INSTALL_TARGET
,
LIB_DEPENDS
, MAKE_ENV
,
MAKE_FLAGS
, PKG_ARGS
,
PSEUDO_FLAVORS
,
TEST_DEPENDS
,
REORDER_DEPENDENCIES
,
RUN_DEPENDS
, SUBST_VARS
,
WANTLIB
.
Some modules correspond to extra ports that will be used mostly as
BUILD_DEPENDS
or
RUN_DEPENDS
. Such modules can safely append values
directly to the BUILD_DEPENDS
,
RUN_DEPENDS
, LIB_DEPENDS
,
and WANTLIB
variables, as long as they also define
module-specific variables for all runtime dependencies.
Simple client ports will use the module directly, and thus inherit extra build and runtime dependencies.
More sophisticated ports can use
MULTI_PACKAGES
to select specific behavior:
build-time dependencies will always be needed. Runtime dependencies will be
selected on a subpackage basis, since runtime dependencies such as
LIB_DEPENDS-sub
do not inherit the default
LIB_DEPENDS
value. The client port's author must
only bear in mind that external modules may add values to the default
WANTLIB
, LIB_DEPENDS
, and
RUN_DEPENDS
, and thus that it is not safe to inherit
from it blindly.
Modules are imported during
.include
<bsd.port.mk>
Thus they can be affected by user choices such as setting a
variable to Yes or No. Modules may make decisions based on documented
MODFOO_BEHAVIOR
values.
When modules are processed, only a few
bsd.port.mk(5) variables
are already defined. Modules may depend upon the following variables already
having a sane value: DISTDIR
,
LOCALBASE
, NO_DEPENDS
,
PKGPATH
, PORTSDIR
,
X11BASE
and all arch-dependent constants from
bsd.port.arch.mk(5),
such as PROPERTIES
or
LP64_ARCHS
. Note that this is only relevant for
tests. It is perfectly okay to define variables or targets that depend on
the basic ports framework without having to care whether that variable is
already defined, since make(1)
performs lazy evaluation.
The following modules are available.
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}
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.
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
.
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:
fetch
, static dependencies ("crates")
listed in MODCARGO_CRATES
are downloaded using
MODCARGO_DIST_SUBDIR
as
DIST_SUBDIR
. During
post-extract
, crates defined in
MODCARGO_CRATES
are moved to the
MODCARGO_VENDOR_DIR
directory. During
post-patch
, crate-metadata are generated using
devel/cargo-generate-vendor. With
CONFIGURE_STYLE
set to ‘cargo’,
cargo is configured to use MODCARGO_VENDOR_DIR
instead of the standard crates-io network source. Finally, any crates
listed in MODCARGO_CRATES_UPDATE
are updated.
MODCARGO_RUSTFLAGS
can be used to pass custom
flags to all rustc(1)
invocations.
lang/rust,
devel/cargo and
devel/cargo-generate-vendor are added to
BUILD_DEPENDS
. By default
MASTER_SITES9
is used to download the
crates.
This module defines:
This module adds three make(1) targets:
modcargo-metadata
modcargo-gen-crates
MODCARGO_CRATES
list from
Cargo.lock (a preliminary crates list is not required).modcargo-gen-crates-licenses
MODCARGO_CRATES
list with license
information from crates present in the
MODCARGO_VENDOR_DIR
directory.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
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.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:
CONFIGURE_SCRIPT
,
CONFIGURE_ARGS
and
MODPMK_configure
. It appends
devel/pmk to
BUILD_DEPENDS
.If CONFIGURE_STYLE
was not set before,
sets its value to ‘qmake’. If
CONFIGURE_STYLE
contains ‘qmake’
the module will define each of the do-build and
do-install targets, unless port already defines
one; also, SEPARATE_BUILD
will be set to
‘Yes’ unless it's already set to some value. Also, unless
NO_TEST
is set, the
do-test target will be defined.
The following variables could be used in qmake-based ports:
MODQMAKE_ARGS
MODQMAKE_INSTALL_ROOT
MODQMAKE_PROJECTS
MODQMAKE_RECURSIVE
MODQMAKE_PROJECTS
will be processed during
configure stage, and their descendants will be visited during main
build phase. Sometimes a qmake project processing depends on files
generated by other qmake project during build, and recursive builds
break this. For Qt4+ defaults to ‘Yes’, and Qt3 doesn't
support recursive configuring.MODQMAKE_build
MODQMAKE_PROJECTS
provided. To be used in
complicated cases, when port have to use its own
do-build target or mix different
CONFIGURE_STYLE
values.MODQMAKE_install
MODQMAKE_build
, but used in
do-install stage.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.PKG_ARCH
and EXTRACT_SUFX
.
Appends to CATEGORIES
. When
TYPEFACE
is set in combination with
V
or VERSION
it sets
PKGNAME
. TYPEFACE
should
be set to the name of the typeface. This sets
FONTDIR
using said typeface name.
FONTTYPES
defaults to `ttf' but can be set to
include the extenions of fonts which are to be installed. Also sets
FONT_DISTDIR
. A do-install
target is provided if the port tself does not provide it.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
.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
.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
.MODCLANG_LANGS
(e.g. c++). Sets MODCLANG_VERSION
which is also
appended to SUBST_VARS
.ONLY_FOR_ARCHS
,
MODGHC_VER
, BUILD_DEPENDS
,
and RUN_DEPENDS
. Build and further actions are
based on the list of values in MODGHC_BUILD
:
PKGNAME
will be added,Also affects CATEGORIES
,
CONFIGURE_STYLE
and
SUBST_VARS
. do-build
,
do-install
and do-test
targets are provided if the port itself didn't set them. If
register has been set, the PLIST needs to be
modified in order to add the relevant @exec/@unexec lines. This module
will run the Setup script and ensure the documentation will be built (if
haddock has been set), and that the package is
registered as a library usable by lang/ghc (if
register has been set). Extra arguments and
environment additions for the Setup configure command can be specified
with MODGHC_SETUP_CONF_ARGS
and
MODGHC_SETUP_CONF_ENV
.
ALL_TARGET
to
be set to canonical Go import path of port. (Module sets it automatically
for ports that use GH_ACCOUNT
and
GH_PROJECT
macros.)
During execution of pre-configure
target module moves source code from
${MODGO_SUBDIR} to
${WRKSRC}, subdirectory of
${MODGO_WORKSPACE} - specially-crafted Go
workspace located at ${WRKDIR}/go. During
do-build
module calls “go install”
with GOPATH
set to
${MODGO_WORKSPACE}, runs its output through sed
to prevent writes outside WRKDIR
sandbox and
sends output to sh(1). During
do-install
it copies executables from
${MODGO_WORKSPACE}/bin to
${PREFIX}/bin, and/or directories
${MODGO_WORKSPACE}/pkg and
${MODGO_WORKSPACE}/src to
${PREFIX}/go, depending on
MODGO_TYPE
contents.
Sets BUILD_DEPENDS
,
RUN_DEPENDS
, ALL_TARGET
,
TEST_TARGET
,
ONLY_FOR_ARCHS
,
SEPARATE_BUILD
, and
WRKSRC
.
Appends to CATEGORIES
.
Defines:
MODGO_TYPE
Defaults to bin.
MODGO_WORKSPACE
MODGO_SUBDIR
MODGO_SETUP_WORKSPACE
pre-configure
target.MODGO_BUILDDEP
MODGO_BUILD_DEPENDS
are appended to port's
BUILD_DEPENDS
. Defaults to
Yes.MODGO_MODNAME
MODGO_MODULES
,
MODGO_MODFILES
and
MODGO_VERSION
need to be defined as well.
Setting this will also set ALL_TARGET
. When
MODGO_MODFILES
is set, and a "cmd"
directory is found in WRKSRC
,
"cmd/..." is appended to ALL_TARGET
in do-build
automatically.MODGO_VERSION
MODGO_MODULES
MODGO_MODFILES
Additionally defines MODGO_PACKAGES
,
MODGO_SOURCES
and
MODGO_TOOLS
(paths for installed Go packages,
sources and tools respectively), MODGO_CMD
and
MODGO_FLAGS
(source code build command and flags
passed as its arguments), MODGO_LDFLAGS
,
MODGO_BUILD_CMD
and
MODGO_TEST_CMD
(commands for building and
testing go packages; normally called with canonical Go package names as
arguments), MODGO_{BUILD,INSTALL,TEST}_TARGET
and MODGO_{BUILD,RUN}_DEPENDS
.
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
.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.RUN_DEPENDS
and
BUILD_DEPENDS
. Recognizes two additional types of
CONFIGURE_STYLE
s, "npm" and "npm
ext". "npm ext" should be used for npm packages that
contain C++ extensions which need to be compiled. "npm" should
be used for other npm packages. If regression tests are included that can
be run using devel/node-expresso, append
"expresso" to CONFIGURE_STYLE
.
devel/node-expresso will be appended to
TEST_DEPENDS
and a default
MODNODE_TEST_TARGET
will be defined, along with a
do-test
target if it has not already been set. If
"expresso" isn't appended to
CONFIGURE_STYLE
,
TEST_TARGET
will be set to "test". One
of these two CONFIGURE_STYLE
s should be used or
the module doesn't affect anything except
RUN_DEPENDS
and
BUILD_DEPENDS
. Requires
NPM_NAME
to be set to the name of the npm package.
Uses NPM_NAME
and
NPM_VERSION
to set
DISTNAME
, and PKGNAME
, and
MASTER_SITES
. If the npm package depends on other
npm packages, the npm package names it depends on should be listed in
MODNODE_DEPENDS
. Adds default
do_build
and do_install
tasks, and you can reference the default implementations via
MODNODE_BUILD_TARGET
and
MODNODE_INSTALL_TARGET
.BUILD_DEPENDS
and
MAKE_ENV
. This selects a %%native%% plist fragment
and ocaml_native
property depending on whether the
architecture supports native compilation. If dynamic linking is supported
on the native architecture, the %%dynlink%% plist fragment and
ocaml_native_dynlink
property is set. When
CONFIGURE_STYLE
is set to `oasis', overrides for
the do-build
, do-install
,
and do-test
targets are added.MODPHP_RUN_DEPENDS
,
MODPHP_LIB_DEPENDS
,
MODPHP_WANTLIB
,
MODPHP_BIN
, MODPHP_PHPIZE
,
MODPHP_PHP_CONFIG
,
MODPHP_INCDIR
and
MODPHP_LIBDIR
. Adds to
RUN_DEPENDS
and
BUILD_DEPENDS
unless
MODPHP_RUNDEP
or
MODPHP_BUILDDEP
are set. If
MODPHP_DO_PHPIZE
is set, prepares a build
environment for extensions that use phpize.
Ports using PDO for database connectivity often have a choice
of dependencies (pdo_sqlite, pdo_mysql, pdo_pgsql and others). The
module constructs MODPHP_PDO_DEPENDS
from the
PDO types listed in MODPHP_PDO_ALLOWED
(defaulting to "sqlite mysql pgsql"). This can be added to
RUN_DEPENDS
and allows any of these PDO packages
to satisfy the dependency, with MODPHP_PDO_PREF
(sqlite by default) chosen if none are installed.
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
.MODPY_VERSION
,
MODPY_BIN
, MODPY_INCDIR
,
MODPY_LIBDIR
,
MODPY_SITEPKG
,
MODPY_SETUP
,
MODPY_TEST_DIR
,
MODPY_TEST_LOCALE
,
MODPY_WANTLIB
,
MODPY_LIB_DEPENDS
,
MODPY_RUN_DEPENDS
,
MODPY_TEST_DEPENDS
,
MODPY_BUILD_DEPENDS
, and
MODPY_ADJ_FILES
. Appends to
RUN_DEPENDS
unless
MODPY_RUNDEP
is set to No. Appends to
BUILD_DEPENDS
unless
MODPY_BUILDDEP
is set to No or
NO_BUILD
is set to Yes. Appends to
TEST_DEPENDS
if
MODPY_PYTEST
is set to Yes unless
MODPY_TESTDEP
is set to No. Appends
MODPY_TEST_LOCALE
to
TEST_ENV
. Changes to the directory specified in
MODPY_TEST_DIR
, by default WRKSRC, before running
tests. MODPY_VERSION
is the default version used
by all python modules. Ports which use the setuptools module should set
MODPY_SETUPTOOLS
to Yes. Ports which use the
pytest module should set MODPY_PYTEST
to Yes.
Arguments can be passed to pytest during test
with
MODPY_PYTEST_ARGS
. All ports that generate
egg-info files should set MODPY_EGG_VERSION
to the
version string used by the
setup
()
function in the port's setup.py. Arguments can be
passed to setup.py during configure
with
MODPY_SETUP_ARGS
. Extra arguments to the build and
install commands can be passed via
MODPY_DISTUTILS_BUILDARGS
and
MODPY_DISTUTILS_INSTALLARGS
. If any files have a
python shebang line which needs to be replaced using MODPY_BIN, list them
in MODPY_ADJ_FILES
. These are prefixed with WRKSRC
and replaced automatically at the end of
pre-configure
. Also affects
CATEGORIES
, MAKE_ENV
,
CONFIGURE_ENV
, and
SUBST_VARS
. May affect the
test
target. If MODPY_PI
is set to Yes it will set HOMEPAGE
and
MASTER_SITES
. The subdirectory can be overridden
with MODPY_PI_DIR
.
Python 2.x places .pyc files in the same directory as the
associated .py file. Python 3.x places these in a separate __pycache__
directory and uses an additional suffix. In some cases, an ABI tag is
also used for names of compiled extensions. The python module defines
variables to allow a single PLIST to be used for both versions. Generate
or update the PLIST using the python3 FLAVOR
,
then edit it to prefix any lines creating
MODPY_PYCACHE
directories with
MODPY_COMMENT
. As python2 and python3 packages
should permit being installed together, it may be necessary to suffix
names of common binaries or directories, or split common files into a
subpackage. If updating the PLIST without using the python3 flavor, take
care not to remove ${MODPY_PYCACHE}, ${MODPY_PYC_MAGIC_TAG}, or
${MODPY_ABI_TAG} variables from the PLIST.
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
.LIB_DEPENDS
and
WANTLIB
according to the values of
MODHEIMDAL_LIB_DEPENDS
, and
MODHEIMDAL_WANTLIB
.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.MODDRUPAL_THEME
is yes, or languages packs if
DRUPAL_LANG
is set to the desired language.
The module may set or add to default values for
HOMEPAGE
, MASTER_SITES
,
PREFIX
, DISTNAME
,
DIST_SUBDIR
, CATEGORIES
,
PKGNAME
, PKG_ARCH
,
WRKDIST
, RUN_DEPENDS
.
Drupal modules normally don't have any build part, just an installation
part that defaults to copying the plugin/theme/language files into the
right location through MODDRUPAL_INSTALL
.
The module sets DRUPAL
to drupal7,
DRUPAL_ROOT
to htdocs/${DRUPAL}
DRUPAL_MODS
to ${DRUPAL_ROOT}/site/all/modules
DRUPAL_THEMES
to ${DRUPAL_ROOT}/site/all/themes
and DRUPAL_TRANSLATIONS
to
${DRUPAL_ROOT}/profiles/standard/translations. So, by default, modules
and themes are installed for all sites, and translations are activated
at install.
DRUPAL_OWNER
,
DRUPAL_GROUP
are set to root, daemon, since
drupal doesn't need to write to any file except the files/ directory and
the site settings (those belong to www instead).
Most modules are actually separate projects on the drupal
site. If MODDRUPAL_PROJECT
is set,
HOMEPAGE
will lead to the corresponding project.
If MODDRUPAL_VERSION
is also set,
DISTNAME
will default to
${MODDRUPAL_PROJECT}-7.x-${MODDRUPAL_VERSION},
MODDRUPAL_PKGNAME will default to
${MODDRUPAL_PROJECT} and
PKGNAME
will default to
drupal7-${MODDRUPAL_PKGNAME}-${MODDRUPAL_VERSION}.
Translations are handled by setting
DRUPAL_LANG
to the language letter code, and by
setting LANGFILES
to a list of module
names/version pairs.
With drupal7, all translations have been put in separate .po files. It has been deemed simplest to pack all translations for a given language into a single package, since translations for non installed modules won't affect anything.
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
.
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
.MODPLONE_VERSION
and
MODZOPE_VERSION
.
MODPLONE_VERSION
is the default version used by
all Plone ports and may be overridden. It appends
www/plone to RUN_DEPENDS
and also sets NO_TEST
to Yes.If both GNOME_PROJECT
and
GNOME_VERSION
are set, this module defines
DISTNAME
, VERSION
,
MASTER_SITES
, adds x11/gnome to
CATEGORIES
and
EXTRACT_SUFX
will default to .tar.xz if unset.
Unless NO_BUILD=Yes
,
textproc/intltool is also appended to
MODULES
and when CONFIGURE_STYLE is set to
gnu or simple,
USE_GMAKE
is set to "Yes".
When CONFIGURE_STYLE is set to gnu or
simple, if none of
AUTOCONF_VERSION
nor
AUTOMAKE_VERSION
are defined, then
"--disable-maintainer-mode" is appended to
CONFIGURE_ARGS
. When CONFIGURE_STYLE is set to
cmake, "-DENABLE_MAINTAINER_MODE=OFF"
and -DSYSCONF_INSTALL_DIR=${SYSCONFDIR} are appended to
CONFIGURE_ARGS.
MODGNOME_CPPFLAGS and MODGNOME_LDFLAGS can be used to add
compiler and linker flags.
CPPFLAGS="-I${LOCALBASE}/include"
and
LDFLAGS="-L${LOCALBASE}/lib"
are
always appended to CONFIGURE_ENV
.
Certain build/run dependencies and configure arguments and
environment can be set by appending desktop-file-utils, docbook,
gobject-introspection, gtk-update-icon-cache, shared-mime-info, vala
and/or yelp to MODGNOME_TOOLS
. They are disabled
otherwise. If MODGNOME_TOOLS
is set to
desktop-file-utils, a dependency on
devel/desktop-file-utils is appended to
MODGNOME_RUN_DEPENDS
and a link to /usr/bin/true
is created under
${WRKDIR}/bin/desktop-file-validate. If
MODGNOME_TOOLS
is set to docbook,
textproc/docbook-xsl is appended to
MODGNOME_BUILD_DEPENDS
. This option is used when
the generation of the man pages included in the source tarball requires
docbook XML/SGML/XSL definitions and stylesheets. If
MODGNOME_TOOLS
is set to gtk-update-icon-cache,
a dependency on x11/gtk+3,-guic is appended to
MODGNOME_RUN_DEPENDS
. If
MODGNOME_TOOLS
is set to shared-mime-info, a
dependency on misc/shared-mime-info is appended
to MODGNOME_RUN_DEPENDS
and a link to
/usr/bin/true is created under
${WRKDIR}/bin/update-mime-database. If
MODGNOME_TOOLS
is set to yelp,
textproc/itstool and
x11/gnome/doc-utils are appended to
MODGNOME_BUILD_DEPENDS
. Furthermore,
x11/gnome/yelp is appended to
MODGNOME_RUN_DEPENDS
if
MODGNOME_TOOLS
also contains
"desktop-file-utils" This option is to be used when any files
are installed into share/gnome/help/ or page
files are installed into share/help/.
MODGNOME_BUILD_DEPENDS
and
MODGNOME_RUN_DEPENDS
are appended to the
corresponding BUILD_DEPENDS
and
RUN_DEPENDS
.
Some tools require the following goo in the PLIST:
desktop-file-utils
@exec %D/bin/update-desktop-database @unexec-delete %D/bin/update-desktop-database
gtk-update-icon-cache ($icon-theme is the theme directory)
@exec %D/bin/gtk-update-icon-cache -q -t %D/share/icons/$icon-theme @unexec-delete %D/bin/gtk-update-icon-cache -q -t %D/share/icons/$icon-theme
shared-mime-info
@exec %D/bin/update-mime-database %D/share/mime @unexec-delete %D/bin/update-mime-database %D/share/mime
MODKDE_VERSION
, which defines what patches and
tweaks should be applied, depending of exact KDE version the ported
software is build against of.MODQT_*
namespace
for simple ports. The qt3 module also defines the same variables under
MODQT3_*
, the qt4 module also defines the same
variables under MODQT4_*
and the qt5 module also
defines the same variables under MODQT5_*
, to
allow ports to use both modules, such as
print/poppler.
Those modules define MODQT*_LIBDIR
as
the libraries location, MODQT*_INCDIR
as the
include files location, MODQT*_QTDIR
as the
global qt directory location,
MODQT*_CONFIGURE_ARGS
as standard GNU
configure-style parameters to locate the include and libraries.
The location of Qt-specific tools
lrelease
, moc
,
qmake
and uic
is
available through MODQT*_LRELEASE
,
MODQT*_MOC
, MODQT*_QMAKE
and MODQT*_UIC
.
MODQT*_OVERRIDE_UIC
controls whether the default
setup will force a value of UIC
or not. The
value of MOC
is always forced to
${MODQT*_MOC}.
In most cases the devel/qmake module
should be used instead of using MODQT*_QMAKE
directly.
qt4 includes
pkg-config(1) files
under a specific location recorded in
MODQT_PKG_CONFIG_PATH
. Qt3 requires the use of
MODQT3_PLUGINS
to correctly locate plugins.
The modules add to CONFIGURE_ENV
,
MAKE_ENV
and MAKE_FLAGS
.
They define appropriate MODQT*_LIB_DEPENDS
and
MODQT*_WANTLIB
.
Note that Qt 4 and Qt 5 has their code split over several
libraries. For the qt4 module the basic WANTLIB
only refers to QtCore, and other libraries should be added as needed.
The qt5 module doesn't set MODQT*_WANTLIB
at
all. Also, Qt 5 consists of many so called Qt modules, and qt5 port
module only refers to qtbase Qt 5 module; other Qt modules should be
added to LIB_DEPENDS
,
BUILD_DEPENDS
or
RUN_DEPENDS
manually.
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.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.
September 15, 2020 | OpenBSD-6.8 |