unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OpenBSD-5.7)
Page:
Section:
Apropos / Subsearch:
optional field

PORT-MODULES(5)             BSD File Formats Manual            PORT-MODULES(5)

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.

     Other modules correspond to shortcuts for using some other ports as
     dependencies without needing to hardcode too much, such as libiconv or
     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/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 exception-
     ally import both modules with MODULES += x11/qt3 x11/qt4 and differenti-
     ate between qt3 and qt4 needs with MODQT3_LIB_DEPENDS and
     MODQT4_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.

     patch         There is a post-patch hook that can be activated by defin-
                   ing MODFOO_post-patch.  It will be run right after
                   post-patch and before REORDER_DEPENDENCIES touches things.

     configure     There is a pre-configure hook that can be activated by
                   defining MODFOO_pre-configure.  It will be run right after
                   pre-configure.  The normal do-configure behavior is to
                   invoke all MODFOO_configure contents that are defined in
                   CONFIGURE_STYLE.  By default, configure will do nothing.

                   Some CONFIGURE_STYLE values, namely perl, gnu, imake,
                   automake, autoconf, and autoupdate 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 pro-
                   cessing will not happen.

     fake          There is a pre-fake hook that can be activated by defining
                   MODFOO_pre-fake.  This will be invoked right after
                   mtree(8), and before the normal pre-fake behavior.

                   This can occasionnally be used for ports that require some
                   specific fake installation setup that will be provided by
                   runtime dependencies.

     install       There is a post-install hook that can be activated by
                   defining MODFOO_post-install.  This will be invoked at the
                   end of install, right after the normal post-install behav-
                   ior.

     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:

     o   Define a variable named MODFOO_BUILD_TARGET that contains the com-
         mands necessary for do-build:

               MODFOO_BUILD_TARGET = cmd1; cmd2

     o   Override do-build only if it's not already defined by the port
         proper:

               .if !target(do-build)
               do-build:
                       @${MODFOO_BUILD_TARGET}
               .endif
     That way, if several modules require specific actions for those targets,
     the end user can choose the appropriate order in which to run the
     actions:

           do-build:
                   @${MODBAR_BUILD_TARGET}
                   @${MODFOO_BUILD_TARGET}
                   ...

OVERRIDING VARIABLE BEHAVIOR
     Some variables can be overridden by modules.  Be very cautious, as this
     can make the module difficult to use, or interact badly with other mod-
     ules.  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, SHARED_ONLY,
     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 behav-
     ior: 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 constant from bsd.port.arch.mk(5), such as
     PROPERTIES or NO_SHARED_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

     converters/libiconv

     cpan          For perl ports coming from CPAN.  Wrapper around the normal
                   perl module that fetches the file from the correct location
                   depending on DISTNAME, and sets a default PKGNAME.  Also
                   affects TEST_DEPENDS, CONFIGURE_STYLE, PKG_ARCH, and
                   CATEGORIES.

                   Some CPAN modules are only indexed by author, set
                   CPAN_AUTHOR=ID to locate the right directory.

                   If no HOMEPAGE is defined, it will default to
                   http://search.cpan.org/dist/${DISTNAME:C/-[^-]*$//}/

                   User settings: set CPAN_REPORT to Yes, CPAN_REPORT_DB to a
                   valid directory, and CPAN_REPORT_FROM to a valid email
                   address to automate the reporting of regression tests to
                   CPAN.

                   If MODCPAN_EXAMPLES is set, the following variables will be
                   set.  MODCPAN_EXAMPLES_DIST will hold the default directory
                   in the distfile with example scripts.  MODCPAN_EXAMPLES_DIR
                   will be set to the standard installation directory for
                   examples.  Sets the post-install target if none has been
                   defined to install the examples, otherwise
                   MODCPAN_POST_INSTALL should be used as such:

                   post-install:
                           ...
                           ${MODCPAN_POST_INSTALL}

     databases/postgresql
                   Adds small framework for testing ports that require running
                   Postgres.  Defines MODPOSTGRESQL_TEST_TARGET which consists
                   actual commands to run in do-test target.  If this target
                   isn't defined, it will be added automatically.

                   The actual test command to be run could be specified in the
                   MODPOSTGRESQL_TEST_CMD.  Default is similar to what
                   bsd.port.mk(5) runs itself.

                   The Postgres server being started will listen on UNIX
                   domain socket only, minimizing impact on running system.
                   The path to directory where socket will be created is set
                   by MODPOSTGRESQL_TEST_PGHOST, defaulting to ${WRKDIR}.  Any
                   local user will be able to connect without password.

                   If the MODPOSTGRESQL_TEST_DBNAME variable is set, the data-
                   base with such name will be set up before running actual
                   test command.  Otherwise (default), the test is responsible
                   to call initdb(1) itself.

                   The databases/postgresql,-server will get added to
                   TEST_DEPENDS, but not to any other *_DEPENDS.

     devel/cmake   Adds devel/cmake to BUILD_DEPENDS and fills up
                   CONFIGURE_ARGS, CONFIGURE_ENV and MAKE_ENV.  Sets up
                   configure target.  If CONFIGURE_STYLE was not set before,
                   sets its value to `cmake'.  Changes default value of
                   SEPARATE_BUILD to `Yes' because modern CMake requires out-
                   of-source build anyway.  Changes REGRESS_TARGET to `test'
                   as this is standard for CMake projects.  Also this module
                   have 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 Make-
                           files.  Default value is `Yes'.
                   Also, 'nojunk' is added to DPB_PROPERTIES because CMake's
                   include files parser cheats too much.

     devel/dconf   Sets CONFIGURE_ARGS, BUILD_DEPENDS and RUN_DEPENDS.  This
                   module is used by ports installing gsettings schemas under
                   ${PREFIX}/share/glib-2.0/schemas/.  It requires the follow-
                   ing goo in the PLIST:

                         @exec %D/bin/glib-compile-schemas %D/share/glib-2.0/schemas >/dev/null
                         @unexec-delete %D/bin/glib-compile-schemas %D/share/glib-2.0/schemas >/dev/null

     devel/gconf2  A link from gconftool-2(1) to true(1) will be put at the
                   front of the PATH.  Sets CONFIGURE_ARGS, BUILD_DEPENDS and
                   RUN_DEPENDS.  According to the values of MODGCONF2_LIBDEP,
                   sets LIB_DEPENDS.  User settings: set MODGCONF2_SCHEMAS_DIR
                   to the directory name under ${LOCALBASE}/share/schemas/
                   where schemas files will be installed.

     devel/gettext

     devel/pmk     Sets CONFIGURE_SCRIPT, CONFIGURE_ARGS and MODPMK_configure.
                   It appends devel/pmk to BUILD_DEPENDS.

     devel/scons   Adds devel/scons to BUILD_DEPENDS.  Sets MODSCONS_BIN and
                   MODSCONS_ENV.  Also defines an overridable MODSCONS_FLAGS.
                   It provides a do-build and do-install targets that can be
                   overridden in the port Makefile.

     devel/waf     Adds devel/waf to BUILD_DEPENDS, lang/python to MODULES,
                   and provides do-configure, do-build, do-install and
                   post-install targets.  do-build, do-install and
                   post-install can be overridden in the port Makefile.

     fortran       Sets MODFORTRAN_LIB_DEPENDS, MODFORTRAN_WANTLIB,
                   MODFORTRAN_BUILD_DEPENDS.  Set MODFORTRAN_COMPILER to `g77'
                   or `gfortran', depending on what the port requires.  The
                   default is `g77'.  The dependencies are chosen according to
                   COMPILER_VERSION and MODFORTRAN_COMPILER.

     gcc4          If COMPILER_VERSION is not gcc4 (defined by
                   /usr/share/mk/bsd.own.mk), and architecture is in
                   MODGCC4_ARCHS, then the gcc4 compilers will be put at the
                   front of the path.  By default, only C language support is
                   included by this module.  If other languages are needed,
                   they must be listed in MODGCC4_LANGS (e.g. c++, fortran).
                   The MODGCC4_VERSION variable can be used to change the ver-
                   sion of gcc.  By default gcc 4.6 is used.  If MODGCC4_LANGS
                   contains c++, this module provides MODGCC4_CPPLIBDEP and
                   MODGCC4_CPPWANTLIB.

     gnu           This module is documented in the main bsd.port.mk(5) man-
                   page.

     imake         This module is documented in the main bsd.port.mk(5) man-
                   page.

     java          Set MODJAVA_VER=x.y to use exactly the JDK x.y,
                   MODJAVA_VER=x.y+ to use any x.y or higher version.  Set
                   MODJAVA_JRERUN=Yes if the port only needs the JRE at run-
                   time.  The module sets JAVA_HOME, ONLY_FOR_ARCHS,
                   MODJAVA_RUN_DEPENDS, MODJAVA_SHARE_DIR, MODJAVA_JAR_DIR,
                   MODJAVA_EXAMPLE_DIR and MODJAVA_DOC_DIR.  It appends to
                   BUILD_DEPENDS, RUN_DEPENDS, CATEGORIES and SUBST_VARS.  If
                   MODJAVA_BUILD=ant then this module provides
                   MODJAVA_BUILD_DIR, MODJAVA_BUILD_FILE and
                   MODJAVA_BUILD_TARGET_NAME, as well as a do-build target (if
                   not already defined).  It heeds NO_BUILD.

     lang/clang    Similar to gcc3 and gcc4 modules.  If architecture is in
                   MODCLANG_ARCHS, the CLang compilers will be put at the
                   front of the path.  By default, only C language support is
                   included by this module.  If other languages are needed,
                   they must be listed in MODCLANG_LANGS (e.g. c++).  Sets
                   MODCLANG_VERSION which is also appended to SUBST_VARS.

     lang/erlang

     lang/ghc      Sets ONLY_FOR_ARCHS, MODGHC_VER, BUILD_DEPENDS, and
                   RUN_DEPENDS.  Build and further actions are based on the
                   list of values in MODGHC_BUILD:

                   nort      no runtime dependency on lang/ghc and hs- prefix
                             will not be added,

                   cabal     get the typical Cabal targets defined,

                   haddock   generate API documentation using devel/haddock,

                   register  create and include register/unregister scripts,

                   hackage   the distfiles are available on Hackage.

                   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 argu-
                   ments and environment additions for the Setup configure
                   command can be specified with MODGHC_SETUP_CONF_ARGS and
                   MODGHC_SETUP_CONF_ENV.

     lang/lua      Sets MODLUA_BIN, MODLUA_DATADIR, MODLUA_DEP,
                   MODLUA_DEP_VERSION, MODLUA_DOCDIR, MODLUA_EXAMPLEDIR,
                   MODLUA_INCL_DIR, MODLUA_LIB, MODLUA_LIBDIR, MODLUA_VERSION,
                   MODLUA_WANTLIB.  Appends to CATEGORIES.  Also appends to
                   BUILD_DEPENDS, unless NO_BUILD has been set to Yes.  Also
                   appends to RUN_DEPENDS, unless MODLUA_RUNDEP is set to No.
                   Appends MODLUA_VERSION, MODLUA_LIB, MODLUA_INCL_DIR,
                   MODLUA_EXAMPLEDIR, MODLUA_DOCDIR, MODLUA_LIBDIR,
                   MODLUA_DATADIR, MODLUA_DEP, MODLUA_DEP_VERSION, MODLUA_BIN
                   to SUBST_VARS.  MODLUA_DEFAULT_VERSION is set to 5.1.
                   MODLUA_VERSION is set to MODLUA_DEFAULT_VERSION by default.
                   Ports can be built with two lua versions.  If no FLAVOR is
                   set it defaults to MODLUA_DEAFULT_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 fla-
                   vor: MODLUA_BUILD_DEPENDS, MODLUA_TEST_DEPENDS,
                   MODLUA_RUN_DEPENDS.

     lang/mono     Sets MODMONO_ONLY_FOR_ARCHS, CONFIGURE_ENV, MAKE_FLAGS,
                   MODMONO_BUILD_DEPENDS and MODMONO_RUN_DEPENDS.  If
                   MODMONO_DEPS is set to Yes, lang/mono is appended to
                   BUILD_DEPENDS and RUN_DEPENDS.  If MODMONO_NANT is set to
                   Yes, NANT and NANT_FLAGS are set, devel/nant is appended to
                   BUILD_DEPENDS and a do-build and do-install targets are
                   provided to use nant for building.  If these targets are
                   already defined, one can use MODMONO_BUILD_TARGET and
                   MODMONO_INSTALL_TARGET instead in the corresponding target.
                   DLLMAP_FILES defines in which files the module will substi-
                   tute hardcoded shared library versions using a
                   post-configure target.

     lang/node     Adds common dependencies to 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 appened 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.

     lang/ocaml    Appends to BUILD_DEPENDS and MAKE_ENV.  This selects a
                   %%native%% plist fragment and ocaml_native property depend-
                   ing on whether the architecture supports native compila-
                   tion.  If dynamic linking is supported on the native archi-
                   tecture, the %%dynlink%% plist fragment and
                   ocaml_native_dynlink property is set.  When CONFIGURE_STYLE
                   is set to `oasis', overrides for the do-build, do-install
                   and do-test targets are added.

     lang/php/pecl
                   Used for ports for PHP PECL extensions.  Sets default
                   MASTER_SITES, HOMEPAGE, EXTRACT_SUFX, DESTDIRNAME,
                   MODPHP_DO_SAMPLE, MODPHP_DO_PHPIZE, AUTOCONF_VERSION,
                   AUTOMAKE_VERSION, LIBTOOL_FLAGS.  Provides a default
                   TEST_TARGET and TEST_FLAGS unless NO_TEST or a do-test tar-
                   get is defined.  Adds common dependencies to RUN_DEPENDS
                   and BUILD_DEPENDS.  Sets a default PKGNAME and appends to
                   CATEGORIES.

     lang/python   Sets MODPY_VERSION, MODPY_BIN, MODPY_INCDIR, MODPY_LIBDIR,
                   MODPY_SITEPKG, MODPY_SETUP, MODPY_WANTLIB,
                   MODPY_LIB_DEPENDS, MODPY_RUN_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.
                   MODPY_VERSION is the default version used by all python
                   modules.  Ports which use the setuptools module should set
                   MODPY_SETUPTOOLS to Yes.  All ports that generate egg-info
                   files should set MODPY_EGG_VERSION to the version string
                   used by the port's setup.py setup() function.  Extra argu-
                   ments 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, SHARED_ONLY, and SUBST_VARS.  May
                   affect the test target.

                   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.  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_PYCOMMENT.
                   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}
                   and ${MODPY_PYC_MAGIC_TAG} variables from the PLIST.

     lang/ruby     See ruby-module(5).

     lang/tcl      Sets MODTCL_VERSION, MODTCL_BIN, MODTCL_INCDIR,
                   MODTCL_LIBDIR, MODTCL_BUILD_DEPENDS, MODTCL_RUN_DEPENDS,
                   MODTCL_LIB, MODTCL_LIB_DEPENDS, and MODTCL_CONFIG.
                   MODTCL_VERSION is the default version used by all Tcl ports
                   and may be overridden.  Provides MODTCL_TCLSH_ADJ and
                   MODTCL_WISH_ADJ shell fragments to patch the interpreter
                   path in executable scripts.  Also affects CATEGORIES and
                   SUBST_VARS.

     perl          This module is documented in the main bsd.port.mk(5) man-
                   page.

     security/heimdal
                   A link from ${LOCALBASE}/heimdal/bin/krb5-config to
                   krb5-config(1) will be put at the front of the path.  Sets
                   LIB_DEPENDS and WANTLIB according to the values of
                   MODHEIMDAL_LIB_DEPENDS, and MODHEIMDAL_WANTLIB.

     textproc/intltool
                   Sets MODINTLTOOL_OVERRIDE.  textproc/intltool is added to
                   BUILD_DEPENDS.  MODINTLTOOL_OVERRIDE changes the paths of
                   INTLTOOL_EXTRACT, INTLTOOL_MERGE and INTLTOOL_UPDATE to use
                   the installed versions of intltool-extract, intltool-merge
                   and intltool-update, instead of the version's packages into
                   the distfile of the port using this module.  Also affects
                   CONFIGURE_ENV, MAKE_ENV and MAKE_FLAGS by appending
                   MODINTLTOOL_OVERRIDE to them.

     www/drupal6   This module is legacy.  drupal6 is still supported, but new
                   work should mostly happen in drupal7 land.

     www/drupal7   Can be used to install plugins (default), themes if
                   MODDRUPAL_THEME is yes, or languages packs if DRUPAL_LANG
                   is set to the desired language.

                   The module will set or add to default values for HOMEPAGE,
                   MASTER_SITES, PREFIX, DIST_SUBDIR, CATEGORIES, 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 ${DRU-
                   PAL_ROOT}/site/all/modules DRUPAL_THEMES to ${DRU-
                   PAL_ROOT}/site/all/themes and DRUPAL_TRANSLATIONS to ${DRU-
                   PAL_ROOT}/profiles/standard/translations.  So, by default,
                   modules and themes are installed for all sites, and trans-
                   lations 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).

                   Translations are handled by setting DRUPAL_LANG to the lan-
                   guage 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 trans-
                   lations for a given language into a single package, since
                   translations for non installed modules won't affect any-
                   thing.

     www/horde

     www/mozilla   Sets PKGNAME, HOMEPAGE, MASTER_SITES, DISTNAME, USE_GMAKE,
                   ONLY_FOR_ARCHS and SHARED_ONLY.  EXTRACT_SUFX defaults to
                   .tar.bz2.

                   Adds common dependencies to LIB_DEPENDS, WANTLIB,
                   RUN_DEPENDS and BUILD_DEPENDS.  Sets common CONFIGURE_ARGS,
                   MAKE_ENV and CONFIGURE_ENV.  Sets MOB variable as source
                   directory and MOZ as target directory within do-install.

                   Individual port Makefile must set MOZILLA_PROJECT,
                   MOZILLA_CODENAME, MOZILLA_VERSION, MOZILLA_BRANCH,
                   MOZILLA_LIBS and MOZILLA_DATADIRS variables.  Port can also
                   append values to MOZILLA_SUBST_FILES which contains the
                   list of files to run SUBST_CMD on during pre-configure, and
                   MOZILLA_AUTOCONF_DIRS which contains the list of dirs where
                   AUTOCONF will be run during pre-configure.

     www/pear      Used for PHP PEAR ports.  Sets default MASTER_SITES,
                   EXTRACT_SUFX, PKGNAME.  Sets PREFIX to /var/www.  Sets
                   NO_TEST unless a do-test target is defined.  Adds common
                   dependencies to RUN_DEPENDS and BUILD_DEPENDS, sets
                   MAKE_FILE and FAKE_FLAGS appropriately.  Makes PEAR_LIBDIR
                   and PEAR_PHPBIN available for use in the port.  Sets a
                   default PKGNAME and appends to CATEGORIES.

     www/plone     Sets 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.

     www/zope

     x11/gnome     If both GNOME_PROJECT and GNOME_VERSION are set, this mod-
                   ule 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 USE_GMAKE is set to "Yes".

                   If CONFIGURE_STYLE is set to "gnu" or "simple",
                   CONFIGURE_SHARED is appended to CONFIGURE_ARGS,
                   CPPFLAGS="-I${LOCALBASE}/include" and
                   LDFLAGS="-L${LOCALBASE}/lib" are appended to CONFIGURE_ENV.

                   If none of AUTOCONF_VERSION nor AUTOMAKE_VERSION are
                   defined, then "--disable-maintainer-mode" is appended to
                   CONFIGURE_ARGS.

                   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 desk-
                   top-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 gen-
                   eration 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 depen-
                   dency on x11/gtk+2,-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

     x11/gnustep

     x11/kde

     x11/kde4      Required for building KDE4-enabled ports.  Main variables
                   are: MODKDE4_USE, MODKDE4_VERSION, MODKDE4_DEP_DIR, MOD-
                   KDE4_DEP_VERSION, MODKDE4_FLAVOR.  It's used both for KDE4
                   SC itself and for software built on top of it, e.g.,
                   Digikam.  This module supports several KDE4 trees at the
                   same time, see below.  The following variables are designed
                   to be used in both types of ports:

                   MODKDE4_USE
                            Defines the core components of KDE4 to be used by
                            the port.  Could have zero or more of the follow-
                            ing values, in any order: 'libs', 'runtime',
                            'pim', 'games', 'workspace'.  Could be forced to
                            be empty, this will mean no automated dependen-
                            cies.  If 'libs' is specified, no dependencies on
                            runtime (kde-runtime or kdepim-runtime) will be
                            recorded.  The 'workspace' component implies
                            'runtime'.  The 'games' component is to be used by
                            games and affects default HOMEPAGE, too.  If nei-
                            ther 'libs' or 'runtime' are specified, the
                            'runtime' is implied.  If both 'libs' and
                            'runtime' are specified, then 'runtime' takes
                            precedence (actually, it's a libs+ anyway).  The
                            'pim libs' combination adds dependencies on both
                            kdelibs and kdepimlibs, and 'pim runtime (' or
                            just 'pim') also adds dependencies on both kde-
                            runtime and kdepim-runtime.  Defaults to 'libs'
                            when MODKDE4_RESOURCES is set to 'Yes', and
                            'runtime' otherwise.

                   MODKDE4_DEP_DIR
                            Expands to 'x11/kdeVERSION' where version depends
                            on current MODKDE4_VERSION, see below.  Read-only.

                   MODKDE4_DEP_VERSION
                            Expands to a string to be used in dependency
                            lines, see examples in x11/kde4/* ports.  Read-
                            only.

                   MODKDE4_RESOURCES
                            Should be set to 'Yes' for ports that only provide
                            non-executable stuff like icons, localization
                            files and so on.  Affects FLAVORS, MODKDE4_NO_QT,
                            MODKDE4_USE, MODULES, PKG_ARCH and SUBST_VARS
                            variables.  Defaults to 'No'.

                   MODKDE4_INCLUDE_DIR
                            Path where KDE4 headers to be placed/searched for,
                            relative to PREFIX.  Read-only.

                   MODKDE4_LIB_DIR
                            Path where KDE4 headers to be placed/searched for,
                            relative to PREFIX.  Read-only.

                   KDE4LIB  Shorter synonym for MODKDE4_LIB_DIR, to be used in
                            plists and WANTLIB declarations.  Read-only.

                   MODKDE4_FIX_GETTEXT
                            If set to 'Yes', adds an additional step before
                            building port that searches for KDE-specific calls
                            of GETTEXT_PROCESS_PO_FILES() CMake command and
                            tweaks them to be compatible with the one from
                            FindGettext.cmake module provided by CMake itself.
                            Defaults to 'Yes'.

                   MODKDE4_SYSCONF_FILES
                            Some KDE ports install files under ${SYSCONFDIR}.
                            We want to have them under
                            ${PREFIX}/share/examples or such, and just be
                            @sample'd under ${SYSCONFDIR}.  So add 'file/dir
                            destination' pairs to this variable, and appropri-
                            ate @sample lines to packing list, e.g.:

                                  # in Makefile:
                                  MODKDE4_SYSCONF_FILES = dbus-1      share/examples

                                  # in PLIST:
                                  share/examples/dbus-1/system.d/org.kde.baloo.filewatch.conf
                                  @sample ${SYSCONFDIR}/dbus-1/system.d/org.kde.baloo.filewatch.conf

                   The following variables are mostly used only inside KDE4
                   SC:

                   MODKDE4_LIB_LINKS
                            If set to 'Yes', soft links for shared libraries
                            in ${PREFIX}/lib to ${MODKDE4_LIB_DIR} will be
                            created.  Used to distinguish libraries from dif-
                            ferent KDE versions (3, 4...).  Defaults to 'No'.

                   KDE4_ONLY
                            If set to 'Yes', sets the dpb(1) tag to 'kde4'.
                            Defaults to 'No' when MODKDE4_USE is empty, and to
                            'Yes' otherwise.

                   The following variables are likely to be used only outside
                   KDE4 SC:

                   MODKDE4_NO_QT
                            If set to 'Yes', avoids automatic addition of
                            x11/qt4 to MODULES.

                   The x11/kde4 module supports co-existence of different KDE4
                   SC version ports subtrees.  There always is a so-called
                   stable tree in ${PORTSDIR}/x11/kde4 and additional trees
                   are placed in ${PORTSDIR}/x11/kdeXYZ, where 'XYZ' corre-
                   spond to the 'X.Y.Z' KDE version.  So, say, KDE 4.12.4 tree
                   should be placed in ${PORTSDIR}/x11/kde4124 directory.  The
                   process of preparing a new KDE SC version subtree is auto-
                   mated, just use kde-release-helper script:

                         cd ${PORTSDIR}/x11/kde4
                         ./kde-release-helper prepare 4.12.4
                   This will copy the x11/kde4 subtree to x11/kde4124 and
                   strip it: remove REVISION marks, remove distinfo files and
                   so on.

                   To access the new version then you'll need to add appropri-
                   ate values at the top of x11/kde4 module file itself.  Then
                   you be able to use automatically created 'kdeXYZ' FLAVOR to
                   reference corresponding KDE4 SC version outside x11/kde4*.

                   The x11/kde4 module sets the following variables unless
                   they're already set by a port: CONFIGURE_STYLE,
                   EXTRACT_SUFX, ONLY_FOR_ARCHS, PORTHOME, SEPARATE_BUILD and
                   SHARED_ONLY.

                   The x11/kde4 module modifies the following variables if
                   needed: BUILD_DEPENDS, CONFIGURE_ARGS, CONFIGURE_ENV,
                   LIB_DEPENDS, RUN_DEPENDS, and WANTLIB.

                   The x11/kde4 module automatically adds devel/cmake to
                   MODULES unless NO_BUILD is set to 'Yes'.  The x11/kde4 mod-
                   ule automatically adds x11/qt4 to MODULES unless
                   MODKDE4_NO_QT is set to 'Yes'.  The x11/kde4 module auto-
                   matically adds gcc4 to MODULES unless MODKDE4_RESOURCES is
                   set to 'Yes'.

     x11/qt3 and x11/qt4
                   Both qt modules share a common MODQT_* namespace for simple
                   ports.  The qt3 module also defines the same variables
                   under MODQT3_* and the qt4 module also defines the same
                   variables under MODQT4_*, to allow ports to use both mod-
                   ules, such as print/poppler.

                   Those modules define MODQT*_LIBDIR as the libraries loca-
                   tion, 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 moc and uic is available
                   through MODQT*_MOC 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}.  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 qt4 has split its code over sev-
                   eral libraries, so the basic WANTLIB only refers to QtCore.
                   Other libraries should be added as needed.

     x11/tk        Sets MODTK_VERSION, MODTK_BIN, MODTK_INCDIR, MODTK_LIBDIR,
                   MODTK_BUILD_DEPENDS, MODTK_RUN_DEPENDS, MODTK_LIB,
                   MODTK_LIB_DEPENDS, and MODTK_CONFIG.  MODTK_VERSION is the
                   default version used by all Tk ports and may be overridden.
                   Automatically adds the lang/tcl module, provides a default
                   MODTCL_VERSION to match MODTK_VERSION, and affects
                   CATEGORIES and SUBST_VARS.  Note the MODTCL_WISH_ADJ shell
                   fragment in the lang/tcl module.

     x11/xfce4     Sets DIST_SUBDIR, EXTRACT_SUFX, CONFIGURE_STYLE,
                   CONFIGURE_ENV and USE_GMAKE.  If MODXFCE_ICON_CACHE is set
                   to yes, it adds x11/gtk+2,-guic to RUN_DEPENDS.  Unless
                   XFCE_NO_SRC is set, devel/gettext and textproc/intltool are
                   added to MODULES.  Also affects CATEGORIES.

                   Xfce ports can be divided into five categories: core
                   libraries and applications, goodies, artwork, thunar plug-
                   ins, and panel plugins.  HOMEPAGE, MASTER_SITES and
                   DISTNAME are built using XFCE_VERSION (which defaults to
                   XFCE_DESKTOP_VERSION if not set) and either XFCE_PROJECT,
                   XFCE_GOODIE, XFCE_ARTWORK, THUNAR_PLUGIN or XFCE_PLUGIN.
                   One of the latter has to be provided by the port Makefile.

SEE ALSO
     make(1), bsd.port.mk(5), ports(7)

BSD                              May 23, 2017                              BSD