| 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.
extractpost-extract hook that can be activated
by defining MODFOO_post-extract. It will be run
right after post-extract.patchpost-patch hook that can be activated
by defining MODFOO_post-patch. It will be run
right after post-patch.gengen hook that can be activated by
defining MODFOO_gen. It will be run right after
do-gen and before
REORDER_DEPENDENCIES touches things.configurepre-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.
fakepre-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.
installpost-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 ?= valueand provide a module-specific variable with the same value:
MODFOO_VARIABLE = valueThe 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-metadatamodcargo-gen-cratesMODCARGO_CRATES list from
Cargo.lock (a preliminary crates list is not required).modcargo-gen-crates-licensesMODCARGO_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_ARGSMODQMAKE_INSTALL_ROOTMODQMAKE_PROJECTSMODQMAKE_RECURSIVEMODQMAKE_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_buildMODQMAKE_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_installMODQMAKE_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_TYPEDefaults to bin.
MODGO_WORKSPACEMODGO_SUBDIRMODGO_SETUP_WORKSPACEpre-configure
target.MODGO_BUILDDEPMODGO_BUILD_DEPENDS are appended to port's
BUILD_DEPENDS. Defaults to
Yes.MODGO_MODNAMEMODGO_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_VERSIONMODGO_MODULESMODGO_MODFILESAdditionally 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_STYLEs, "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_STYLEs 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 |