Index: head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml
===================================================================
--- head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml (revision 53466)
+++ head/en_US.ISO8859-1/books/porters-handbook/special/chapter.xml (revision 53467)
@@ -1,7142 +1,7142 @@
Special ConsiderationsThis section explains the most common things to consider when
creating a port.Stagingbsd.port.mk expects ports to work
with a stage directory. This means that a port
must not install files directly to the regular destination
directories (that is, under PREFIX, for
example) but instead into a separate directory from which the
package is then built. In many cases, this does not require
root privileges, making it possible to build packages as an
unprivileged user. With staging, the port is built and
installed into the stage directory,
STAGEDIR. A package is created from the
stage directory and then installed on the system. Automake
tools refer to this concept as DESTDIR, but
in &os;, DESTDIR has a different meaning
(see ).No port really needs to be root. It
can mostly be avoided by using USES=uidfix.
If the port still runs commands like &man.chown.8;,
&man.chgrp.1;, or forces owner or group with &man.install.1;
then use USES=fakeroot
to fake those calls. Some patching of the port's
Makefiles will be needed.Meta ports, or ports that do not install files themselves
but only depend on other ports, must avoid needlessly
extracting the &man.mtree.8; to the stage directory. This is
the basic directory layout of the package, and these empty
directories will be seen as orphans. To prevent
&man.mtree.8; extraction, add this line:NO_MTREE= yesMetaports should use USES=metaport.
It sets up defaults for ports that do not fetch, build, or
install anything.Staging is enabled by prepending
STAGEDIR to paths used in the
pre-install,
do-install, and
post-install targets (see the
examples through the book). Typically, this includes
PREFIX, ETCDIR,
DATADIR, EXAMPLESDIR,
MANPREFIX, DOCSDIR, and
so on. Directories should be created as part of the
post-install target. Avoid using
absolute paths whenever possible.Ports that install kernel modules must prepend
STAGEDIR to their destination, by default
/boot/modules.Handling Symbolic LinksWhen creating a symlink, there are two cases, either the
source and target are both within
${PREFIX}. In that case, use
${RLN}. In the other case, if one or both
of the paths are outside of ${PREFIX}
use ${LN} -s and only prepend
${STAGEDIR} to the target's path.Inside ${PREFIX}, Create Relative
Symbolic Links${RLN} uses &man.install.1;'s
relative symbolic feature which frees the porter of
computing the relative path.${RLN} ${STAGEDIR}${PREFIX}/lib/libfoo.so.42 ${STAGEDIR}${PREFIX}/lib/libfoo.soWill generate:&prompt.user; ls -lF ${STAGEDIR}${PREFIX}/lib
lrwxr-xr-x 1 nobody nobody 181 Aug 3 11:27 libfoo.so@ -> libfoo.so.42
-rwxr-xr-x 1 nobody nobody 15 Aug 3 11:24 libfoo.so.42*When used with paths not in the same directory:${RLN} ${STAGEDIR}${PREFIX}/libexec/foo/bar ${STAGEDIR}${PREFIX}/bin/barWill automatically generate the relative symbolic
links:&prompt.user; ls -lF ${STAGEDIR}${PREFIX}/bin
lrwxr-xr-x 1 nobody nobody 181 Aug 3 11:27 bar@ -> ../libexec/foo/barOutside ${PREFIX}, Create Absolute
Symbolic LinksWhen creating a symbolic link outside of
${PREFIX}, the source must not contain
${STAGEDIR}, the target, however,
must:${LN} -sf /var/cache/${PORTNAME} ${STAGEDIR}${PREFIX}/share/${PORTNAME}Will generate:&prompt.user; ls -lF ${STAGEDIRDIR}${PREFIX}/share
lrwxr-xr-x 1 nobody nobody 181 Aug 3 11:27 foo@ -> /var/cache/fooBundled LibrariesThis section explains why bundled dependencies are
considered bad and what to do about them.Why Bundled Libraries Are BadSome software requires the porter to locate third-party
libraries and add the required dependencies to the port.
Other software bundles all necessary libraries into the
distribution file. The second approach seems easier at
first, but there are some serious drawbacks:This list is loosely based on the Fedora
and Gentoo
wikis, both licensed under the CC-BY-SA
3.0 license.SecurityIf vulnerabilities are found in the upstream library
and fixed there, they might not be fixed in the library
bundled with the port. One reason could be that the
author is not aware of the problem. This means that the
porter must fix them, or upgrade to a non-vulnerable
version, and send a patch to the author. This all takes
time, which results in software being vulnerable longer
than necessary. This in turn makes it harder to
coordinate a fix without unnecessarily leaking
information about the vulnerability.BugsThis problem is similar to the problem with security
in the last paragraph, but generally less severe.ForkingIt is easier for the author to fork the upstream
library once it is bundled. While convenient on first
sight, it means that the code diverges from upstream
making it harder to address security or other problems
with the software. A reason for this is that patching
becomes harder.Another problem of forking is that because code
diverges from upstream, bugs get solved over and over
again instead of just once at a central location. This
defeats the idea of open source software in the first
place.Symbol collisionWhen a library is installed on the system, it might
collide with the bundled version. This can cause
immediate errors at compile or link time. It can also
cause errors when running the program which might be
harder to track down. The latter problem could be
caused because the versions of the two libraries are
incompatible.LicensingWhen bundling projects from different sources,
license issues can arise more easily, especially when
licenses are incompatible.Waste of resourcesBundled libraries waste resources on several levels.
It takes longer to build the actual application,
especially if these libraries are already present on the
system. At run-time, they can take up unnecessary
memory when the system-wide library is already loaded by
one program and the bundled library is loaded by another
program.Waste of effortWhen a library needs patches for &os;, these patches
have to be duplicated again in the bundled library.
This wastes developer time because the patches might not
apply cleanly. It can also be hard to notice that these
patches are required in the first place.What to do About Bundled LibrariesWhenever possible, use the unbundled version of the
library by adding a LIB_DEPENDS to the
port. If such a port does not exist yet, consider creating
it.Only use bundled libraries if the upstream has a
good track record on security and using unbundled versions
leads to overly complex patches.In some very special cases, for example emulators, like
Wine, a port has to bundle
libraries, because they are in a different architecture, or
they have been modified to fit the software's use. In that
case, those libraries should not be exposed to other ports
for linking. Add BUNDLE_LIBS=yes to the
port's Makefile. This will tell
&man.pkg.8; to not compute provided libraries. Always ask
the &a.portmgr; before adding this to a port.Shared LibrariesIf the port installs one or more shared libraries, define
a USE_LDCONFIG make variable, which will
instruct a bsd.port.mk to run
${LDCONFIG} -m on the directory
where the new library is installed (usually
PREFIX/lib) during
post-install target to register it
into the shared library cache. This variable, when defined,
will also facilitate addition of an appropriate
@exec /sbin/ldconfig -m and
@unexec /sbin/ldconfig -R pair into
pkg-plist, so that a user who
installed the package can start using the shared library
immediately and de-installation will not cause the system to
still believe the library is there.USE_LDCONFIG= yesThe default directory can be overridden by
setting USE_LDCONFIG to a list of
directories into which shared libraries are to be installed.
For example, if the port installs shared libraries into
PREFIX/lib/foo and
PREFIX/lib/bar
use this in
Makefile:USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/barPlease double-check, often this is not necessary at all or
can be avoided through -rpath or setting
LD_RUN_PATH during linking (see
lang/mosml for an
example), or through a shell-wrapper which sets
LD_LIBRARY_PATH before invoking the binary,
like www/seamonkey
does.When installing 32-bit libraries on 64-bit system, use
USE_LDCONFIG32 instead.If the software uses autotools, and specifically
libtool, add USES=libtool.When the major library version number increments in the
update to the new port version, all other ports that link to
the affected library must have their
PORTREVISION incremented, to force
recompilation with the new library version.Ports with Distribution Restrictions or Legal
ConcernsLicenses vary, and some of them place restrictions on how
the application can be packaged, whether it can be sold for
profit, and so on.It is the responsibility of a porter to read the
licensing terms of the software and make sure that the
&os; project will not be held accountable for violating
them by redistributing the source or compiled binaries
either via FTP/HTTP or CD-ROM. If in doubt, please contact
the &a.ports;.In situations like this, the variables described in the
next sections can be set.NO_PACKAGEThis variable indicates that we may not generate a
binary package of the application. For instance, the
license may disallow binary redistribution, or it may
prohibit distribution of packages created from patched
sources.However, the port's DISTFILES may be
freely mirrored on FTP/HTTP. They may also be distributed
on a CD-ROM (or similar media) unless
NO_CDROM is set as well.If the
binary package is not generally useful, and the application
must always be compiled from the source code, use
NO_PACKAGE. For
example, if the application has configuration information
that is site specific hard coded into it at compile time,
set NO_PACKAGE.Set NO_PACKAGE to a string
describing the reason why the package cannot be
generated.NO_CDROMThis variable alone indicates that, although we are
allowed to generate binary packages, we may put neither
those packages nor the port's DISTFILES
onto a CD-ROM (or similar media) for resale. However, the
binary packages and the port's DISTFILES
will still be available via FTP/HTTP.If this variable is set along with
NO_PACKAGE, then only the port's
DISTFILES will be available, and only via
FTP/HTTP.Set NO_CDROM to a string
describing the reason why the port cannot be redistributed
on CD-ROM. For instance, use this if the port's
license is for non-commercial use
only.NOFETCHFILESFiles defined in NOFETCHFILES
are not fetchable from any of
MASTER_SITES. An example of such a file
is when the file is supplied on CD-ROM by the vendor.Tools which check for the availability of these files
on MASTER_SITES have to ignore these
files and not report about them.RESTRICTEDSet this variable alone if the application's license
permits neither mirroring the application's
DISTFILES nor distributing the binary
package in any way.Do not set NO_CDROM or
NO_PACKAGE along with
RESTRICTED, since the latter variable
implies the former ones.Set RESTRICTED to a string
describing the reason why the port cannot be redistributed.
Typically, this indicates that the port contains proprietary
software and that the user will need to manually download
the DISTFILES, possibly after registering
for the software or agreeing to accept the terms of an
EULA.RESTRICTED_FILESWhen RESTRICTED or
NO_CDROM is set, this variable defaults
to ${DISTFILES} ${PATCHFILES}, otherwise
it is empty. If only some of the distribution files are
restricted, then set this variable to list them.LEGAL_TEXTIf the port has legal concerns not addressed by the
above variables, set LEGAL_TEXT
to a string explaining the concern. For
example, if special permission was obtained for &os; to
redistribute the binary, this variable must indicate
so./usr/ports/LEGAL and
LEGALA port which sets any of the above variables must also
be added to /usr/ports/LEGAL. The
first column is a glob which matches the restricted
distfiles. The second column is the port's origin. The
third column is the output of
make -VLEGAL.ExamplesThe preferred way to state "the distfiles for this port
must be fetched manually" is as follows:.if !exists(${DISTDIR}/${DISTNAME}${EXTRACT_SUFX})
IGNORE= may not be redistributed because of licensing reasons. Please visit some-website to accept their license and download ${DISTFILES} into ${DISTDIR}
.endifThis both informs the user, and sets the proper metadata
on the user's machine for use by automated programs.Note that this stanza must be preceded by an inclusion
of bsd.port.pre.mk.Building MechanismsBuilding Ports in ParallelThe &os; ports framework supports parallel building
using multiple make sub-processes, which
allows SMP systems to utilize all of
their available CPU power, allowing port
builds to be faster and more effective.This is achieved by passing -jX flag
to &man.make.1; running on vendor code. This is the default
build behavior of ports. Unfortunately, not all ports
handle parallel building well and it may be required to
explicitly disable this feature by adding the
MAKE_JOBS_UNSAFE=yes variable. It is
used when a port is known to be broken with
-jX due to race conditions causing
intermittent build failures.When setting MAKE_JOBS_UNSAFE, it
is very important to explain either with a comment in the
Makefile, or at least in the commit
message, why the port does not build
when enabling. Otherwise, it is almost impossible to
either fix the problem, or test if it has been fixed when
committing an update at a later date.make, gmake,
and imakeSeveral differing make
implementations exist. Ported software often requires a
particular implementation, like GNU
make, known in &os; as
gmake.If the port uses GNU make,
add gmake to
USES.MAKE_CMD can be used to reference the
specific command configured by the USES
setting in the port's Makefile.
Only use MAKE_CMD within the
application Makefiles in
WRKSRC to call the
make implementation expected by the
ported software.If the port is an X application that uses
imake to create
Makefiles from
Imakefiles, set USES=
imake.. See the USES=imake
section of for more details.If the port's source Makefile has
something other than all as the
main build target, set ALL_TARGET
accordingly. The same goes for
install and
INSTALL_TARGET.configure ScriptIf the port uses the configure
script to generate Makefile from
Makefile.in, set
GNU_CONFIGURE=yes. To give
extra arguments to the configure script
(the default argument is --prefix=${PREFIX}
--infodir=${PREFIX}/${INFO_PATH}
--mandir=${MANPREFIX}/man
--build=${CONFIGURE_TARGET}), set those
extra arguments in CONFIGURE_ARGS. Extra
environment variables can be passed using
CONFIGURE_ENV.
Variables for Ports That Use
configureVariableMeansGNU_CONFIGUREThe port uses configure
script to prepare build.HAS_CONFIGURESame as GNU_CONFIGURE,
except default configure target is not added to
CONFIGURE_ARGS.CONFIGURE_ARGSAdditional arguments passed to
configure script.CONFIGURE_ENVAdditional environment variables to be set
for configure script run.CONFIGURE_TARGETOverride default configure target. Default
value is
${MACHINE_ARCH}-portbld-freebsd${OSREL}.
Using cmakeFor ports that use CMake,
define USES= cmake.
Variables for Ports That Use
cmakeVariableMeansCMAKE_ARGSPort specific CMake
flags to be passed to the cmake
binary.CMAKE_ONFor each entry in CMAKE_ON, an
enabled boolean value is added to
CMAKE_ARGS. See .CMAKE_OFFFor each entry in CMAKE_OFF, a
disabled boolean value is added to
CMAKE_ARGS. See .CMAKE_BUILD_TYPEType of build (CMake
predefined build profiles). Default is
Release, or
Debug if
WITH_DEBUG is set.CMAKE_SOURCE_PATHPath to the source directory. Default is
${WRKSRC}.CONFIGURE_ENVAdditional environment variables to be set for
the cmake binary.
Variables the Users Can Define for
cmake BuildsVariableMeansCMAKE_NOCOLORDisables color build output. Default not set,
unless BATCH or
PACKAGE_BUILDING are set.
CMake supports these
build profiles: Debug,
Release,
RelWithDebInfo and
MinSizeRel. Debug and
Release profiles respect system
*FLAGS, RelWithDebInfo
and MinSizeRel will set
CFLAGS to -O2 -g and
-Os -DNDEBUG correspondingly. The
lower-cased value of CMAKE_BUILD_TYPE is
exported to PLIST_SUB and must be
used if the port installs
*.cmake
depending on the build type (see
deskutils/strigi for an
example). Please note that some projects may define their own
build profiles and/or force particular build type by setting
CMAKE_BUILD_TYPE in
CMakeLists.txt. To make a port for such
a project respect CFLAGS and
WITH_DEBUG, the
CMAKE_BUILD_TYPE definitions must be
removed from those files.Most CMake-based projects
support an out-of-source method of building. The
out-of-source build for a port is the default setting.
An in-source build can be requested by using the
:insource suffix. With out-of-source
builds, CONFIGURE_WRKSRC,
BUILD_WRKSRC and
INSTALL_WRKSRC will be set to
${WRKDIR}/.build and this
directory will be used to keep all files generated during
configuration and build stages, leaving the source directory
intact.USES= cmake ExampleThis snippet demonstrates the use of
CMake for a port.
CMAKE_SOURCE_PATH is not usually
required, but can be set when the sources are not located
in the top directory, or if only a subset of the project
is intended to be built by the port.USES= cmake
CMAKE_SOURCE_PATH= ${WRKSRC}/subprojectCMAKE_ON and
CMAKE_OFFWhen adding boolean values to
CMAKE_ARGS, it is easier to use the
CMAKE_ON and CMAKE_OFF
variables instead. This:CMAKE_ON= VAR1 VAR2
CMAKE_OFF= VAR3Is equivalent to:CMAKE_ARGS= -DVAR1:BOOL=TRUE -DVAR2:BOOL=TRUE -DVAR3:BOOL=FALSEThis is only for the default values off
CMAKE_ARGS. The helpers described in
use the same
semantics, but for optional values.Using sconsIf the port uses SCons,
define USES=scons.To make third party SConstruct
respect everything that is passed to SCons in
the environment (that is, most importantly,
CC/CXX/CFLAGS/CXXFLAGS), patch
SConstruct so build
Environment is constructed like
this:env = Environment(**ARGUMENTS)It may be then modified with
env.Append and
env.Replace.Building Rust Applications
with cargoFor ports that use Cargo,
define USES=cargo.
Variables the Users Can Define for
cargo BuildsVariableDefaultDescriptionCARGO_CRATESList of crates the port depends on. Each entry
needs to have a format like
cratename-semver for example,
libc-0.2.40. Port maintainers can
generate this list from
Cargo.lock using
make cargo-crates. Manually
bumping crate versions is possible but be mindful of
transitive dependencies.CARGO_FEATURESList of application features to build (space
separated list).CARGO_CARGOTOML${WRKSRC}/Cargo.tomlThe path to the Cargo.toml
to use.CARGO_CARGOLOCK${WRKSRC}/Cargo.lockThe path to the Cargo.lock
to use for make cargo-crates. It
is possible to specify more than one lock file when
necessary.CARGO_ENVA list of environment variables to pass to Cargo
similar to MAKE_ENV.RUSTFLAGSFlags to pass to the Rust compiler.CARGO_CONFIGUREyesUse the default
do-configure.CARGO_UPDATE_ARGSExtra arguments to pass to Cargo during the
configure phase. Valid arguments can be looked up
with cargo update --help.CARGO_BUILDDEPyesAdd a build dependency on
lang/rust.CARGO_CARGO_BIN${LOCALBASE}/bin/cargoLocation of the cargo
binary.CARGO_BUILDyesUse the default
do-build.CARGO_BUILD_ARGSExtra arguments to pass to Cargo during the
build phase. Valid arguments can be looked up with
cargo build --help.CARGO_INSTALLyesUse the default
do-install.CARGO_INSTALL_ARGSExtra arguments to pass to Cargo during the
install phase. Valid arguments can be looked up with
cargo install --help.CARGO_INSTALL_PATH.Path to the crate to install. This is passed
to cargo install via its
--path argument. When multiple
paths are specified cargo install
is run multiple times.CARGO_TESTyesUse the default
do-test.CARGO_TEST_ARGSExtra arguments to pass to Cargo during the test
phase. Valid arguments can be looked up with
cargo test --help.CARGO_TARGET_DIR${WRKDIR}/targetLocation of the cargo output directory.CARGO_DIST_SUBDIRrust/cratesDirectory relative to DISTDIR
where the crate distribution files will be
stored.CARGO_VENDOR_DIR${WRKSRC}/cargo-cratesLocation of the vendor directory where
all crates will be extracted to. Try to keep this
under PATCH_WRKSRC, so that
patches can be applied easily.CARGO_USE_GITHUBnoEnable fetching of crates locked to specific Git
commits on GitHub via GH_TUPLE.
This will try to patch all
Cargo.toml under
WRKDIR to point to the
offline sources instead of fetching them from a
Git repository during the build.CARGO_USE_GITLABnoSame as CARGO_USE_GITHUB
but for GitLab instances and
GL_TUPLE.
Creating a Port for a Simple Rust ApplicationCreating a Cargo based port is a three stage process.
First we need to provide a ports template that fetches the
application distribution file:PORTNAME= tokei
DISTVERSIONPREFIX= v
DISTVERSION= 7.0.2
CATEGORIES= devel
MAINTAINER= tobik@FreeBSD.org
COMMENT= Display statistics about your code
USES= cargo
USE_GITHUB= yes
GH_ACCOUNT= Aaronepower
.include <bsd.port.mk>Generate an initial
distinfo:&prompt.user; make makesum
=> Aaronepower-tokei-v7.0.2_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://codeload.github.com/Aaronepower/tokei/tar.gz/v7.0.2?dummy=/Aaronepower-tokei-v7.0.2_GH0.tar.gz
fetch: https://codeload.github.com/Aaronepower/tokei/tar.gz/v7.0.2?dummy=/Aaronepower-tokei-v7.0.2_GH0.tar.gz: size of remote file is not known
Aaronepower-tokei-v7.0.2_GH0.tar.gz 45 kB 239 kBps 00m00sNow the distribution file is ready to use and we can go
ahead and extract crate dependencies from the bundled
Cargo.lock:&prompt.user; make cargo-crates
CARGO_CRATES= aho-corasick-0.6.4 \
ansi_term-0.11.0 \
arrayvec-0.4.7 \
atty-0.2.9 \
bitflags-1.0.1 \
byteorder-1.2.2 \
[...]The output of this command needs to be pasted directly
into the Makefile:PORTNAME= tokei
DISTVERSIONPREFIX= v
DISTVERSION= 7.0.2
CATEGORIES= devel
MAINTAINER= tobik@FreeBSD.org
COMMENT= Display statistics about your code
USES= cargo
USE_GITHUB= yes
GH_ACCOUNT= Aaronepower
CARGO_CRATES= aho-corasick-0.6.4 \
ansi_term-0.11.0 \
arrayvec-0.4.7 \
atty-0.2.9 \
bitflags-1.0.1 \
byteorder-1.2.2 \
[...]
.include <bsd.port.mk>distinfo needs to be regenerated to
contain all the crate distribution files:&prompt.user; make makesum
=> rust/crates/aho-corasick-0.6.4.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://crates.io/api/v1/crates/aho-corasick/0.6.4/download?dummy=/rust/crates/aho-corasick-0.6.4.tar.gz
rust/crates/aho-corasick-0.6.4.tar.gz 100% of 24 kB 6139 kBps 00m00s
=> rust/crates/ansi_term-0.11.0.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://crates.io/api/v1/crates/ansi_term/0.11.0/download?dummy=/rust/crates/ansi_term-0.11.0.tar.gz
rust/crates/ansi_term-0.11.0.tar.gz 100% of 16 kB 21 MBps 00m00s
=> rust/crates/arrayvec-0.4.7.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://crates.io/api/v1/crates/arrayvec/0.4.7/download?dummy=/rust/crates/arrayvec-0.4.7.tar.gz
rust/crates/arrayvec-0.4.7.tar.gz 100% of 22 kB 3237 kBps 00m00s
=> rust/crates/atty-0.2.9.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://crates.io/api/v1/crates/atty/0.2.9/download?dummy=/rust/crates/atty-0.2.9.tar.gz
rust/crates/atty-0.2.9.tar.gz 100% of 5898 B 81 MBps 00m00s
=> rust/crates/bitflags-1.0.1.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
[...]The port is now ready for a test build and further
adjustments like creating a plist, writing a description,
adding license information, options, etc. as normal.If you are not testing your port in a clean environment
like with Poudriere, remember to
run make clean before any testing.Enabling Additional Application FeaturesSome applications define additional features in their
Cargo.toml. They can be compiled in
by setting CARGO_FEATURES in the
port.Here we enable Tokei's json and
yaml features:CARGO_FEATURES= json yamlListing Crate LicensesCrates have their own licenses. It is important to
know what they are when adding a LICENSE
block to the port (see ). The
helper target
cargo-crates-licenses will try
to list all the licenses of all crates defined in
CARGO_CRATES.&prompt.user; make cargo-crates-licenses
aho-corasick-0.6.4 Unlicense/MIT
ansi_term-0.11.0 MIT
arrayvec-0.4.7 MIT/Apache-2.0
atty-0.2.9 MIT
bitflags-1.0.1 MIT/Apache-2.0
byteorder-1.2.2 Unlicense/MIT
[...]The license names
make cargo-crates-licenses outputs are
SPDX 2.1 licenses expression which do not match the
license names defined in the ports framework. They need
to be translated to the names from
.Using mesonFor ports that use Meson,
define USES=meson.
Variables for Ports That Use
mesonVariableDescriptionMESON_ARGSPort specific Meson
flags to be passed to the meson
binary.MESON_BUILD_DIRPath to the build directory relative to
WRKSRC. Default is
_build.
USES=meson ExampleThis snippet demonstrates the use of
Meson for a port.USES= meson
MESON_ARGS= -Dfoo=enabledBuilding Go
ApplicationsFor ports that use Go,
define USES=go. Refer to for a list of variables that can be
set to control the build process.Creating a Port for a Go Modules Based
ApplicationCreating a Go based port is a five stage process.
First we need to provide a ports template that fetches the
application distribution file:PORTNAME= ghq
DISTVERSIONPREFIX= v
DISTVERSION= 0.12.5
CATEGORIES= devel
MAINTAINER= tobik@FreeBSD.org
COMMENT= Remote repository management made easy
USES= go:modules
USE_GITHUB= yes
GH_ACCOUNT= motemen
.include <bsd.port.mk>Generate an initial
distinfo:&prompt.user; make makesum
===> License MIT accepted by the user
=> motemen-ghq-v0.12.5_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://codeload.github.com/motemen/ghq/tar.gz/v0.12.5?dummy=/motemen-ghq-v0.12.5_GH0.tar.gz
fetch: https://codeload.github.com/motemen/ghq/tar.gz/v0.12.5?dummy=/motemen-ghq-v0.12.5_GH0.tar.gz: size of remote file is not known
motemen-ghq-v0.12.5_GH0.tar.gz 32 kB 177 kBps 00sNow the distribution file is ready to use and we can
extract the required Go module dependencies. This step
requires having
ports-mgmt/modules2tuple
installed:&prompt.user; make gomod-vendor
[...]
GH_TUPLE= \
Songmu:gitconfig:v0.0.2:songmu_gitconfig/vendor/github.com/Songmu/gitconfig \
daviddengcn:go-colortext:186a3d44e920:daviddengcn_go_colortext/vendor/github.com/daviddengcn/go-colortext \
go-yaml:yaml:v2.2.2:go_yaml_yaml/vendor/gopkg.in/yaml.v2 \
golang:net:3ec191127204:golang_net/vendor/golang.org/x/net \
golang:sync:112230192c58:golang_sync/vendor/golang.org/x/sync \
golang:xerrors:3ee3066db522:golang_xerrors/vendor/golang.org/x/xerrors \
motemen:go-colorine:45d19169413a:motemen_go_colorine/vendor/github.com/motemen/go-colorine \
urfave:cli:v1.20.0:urfave_cli/vendor/github.com/urfave/cliThe output of this command needs to be pasted directly
into the Makefile:PORTNAME= ghq
DISTVERSIONPREFIX= v
DISTVERSION= 0.12.5
CATEGORIES= devel
MAINTAINER= tobik@FreeBSD.org
COMMENT= Remote repository management made easy
USES= go:modules
USE_GITHUB= yes
GH_ACCOUNT= motemen
GH_TUPLE= Songmu:gitconfig:v0.0.2:songmu_gitconfig/vendor/github.com/Songmu/gitconfig \
daviddengcn:go-colortext:186a3d44e920:daviddengcn_go_colortext/vendor/github.com/daviddengcn/go-colortext \
go-yaml:yaml:v2.2.2:go_yaml_yaml/vendor/gopkg.in/yaml.v2 \
golang:net:3ec191127204:golang_net/vendor/golang.org/x/net \
golang:sync:112230192c58:golang_sync/vendor/golang.org/x/sync \
golang:xerrors:3ee3066db522:golang_xerrors/vendor/golang.org/x/xerrors \
motemen:go-colorine:45d19169413a:motemen_go_colorine/vendor/github.com/motemen/go-colorine \
urfave:cli:v1.20.0:urfave_cli/vendor/github.com/urfave/cli
.include <bsd.port.mk>distinfo needs to be regenerated to
contain all the distribution files:&prompt.user; make makesum
=> Songmu-gitconfig-v0.0.2_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://codeload.github.com/Songmu/gitconfig/tar.gz/v0.0.2?dummy=/Songmu-gitconfig-v0.0.2_GH0.tar.gz
fetch: https://codeload.github.com/Songmu/gitconfig/tar.gz/v0.0.2?dummy=/Songmu-gitconfig-v0.0.2_GH0.tar.gz: size of remote file is not known
Songmu-gitconfig-v0.0.2_GH0.tar.gz 5662 B 936 kBps 00s
=> daviddengcn-go-colortext-186a3d44e920_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch https://codeload.github.com/daviddengcn/go-colortext/tar.gz/186a3d44e920?dummy=/daviddengcn-go-colortext-186a3d44e920_GH0.tar.gz
fetch: https://codeload.github.com/daviddengcn/go-colortext/tar.gz/186a3d44e920?dummy=/daviddengcn-go-colortext-186a3d44e920_GH0.tar.gz: size of remote file is not known
daviddengcn-go-colortext-186a3d44e920_GH0.tar. 4534 B 1098 kBps 00s
[...]The port is now ready for a test build and further
adjustments like creating a plist, writing a description,
adding license information, options, etc. as normal.If you are not testing your port in a clean environment
like with Poudriere, remember to
run make clean before any testing.Setting Output Binary Name or Installation PathSome ports need to install the resulting binary under a
different name or to a path other than
the default ${PREFIX}/bin. This can be
done by using GO_TARGET tuple syntax,
for example:GO_TARGET= ./cmd/ipfs:ipfs-gowill install ipfs binary as
${PREFIX}/bin/ipfs-go andGO_TARGET= ./dnscrypt-proxy:${PREFIX}/sbin/dnscrypt-proxywill install dnscrypt-proxy to
${PREFIX}/sbin.Using GNU AutotoolsIf a port needs any of the GNU Autotools software, add
USES=autoreconf. See for more information.Using GNU gettextBasic UsageIf the port requires gettext, set
USES= gettext, and the port will inherit
a dependency on libintl.so from
devel/gettext. Other
values for gettext usage are listed in
USES=gettext.A rather common case is a port using
gettext and configure.
Generally, GNU configure should be able
to locate gettext automatically.USES= gettext
GNU_CONFIGURE= yesIf it ever fails to, hints at the location of
gettext can be passed in
CPPFLAGS and LDFLAGS as
follows:USES= gettext
CPPFLAGS+= -I${LOCALBASE}/include
LDFLAGS+= -L${LOCALBASE}/lib
GNU_CONFIGURE= yesOptional UsageSome software products allow for disabling
NLS. For example, through passing
to
configure. In that case, the port must use
gettext conditionally, depending on the
status of the NLS option. For ports of low
to medium complexity, use this idiom:GNU_CONFIGURE= yes
OPTIONS_DEFINE= NLS
OPTIONS_SUB= yes
NLS_USES= gettext
NLS_CONFIGURE_ENABLE= nls
.include <bsd.port.mk>Or using the older way of using options:GNU_CONFIGURE= yes
OPTIONS_DEFINE= NLS
.include <bsd.port.options.mk>
.if ${PORT_OPTIONS:MNLS}
USES+= gettext
PLIST_SUB+= NLS=""
.else
CONFIGURE_ARGS+= --disable-nls
PLIST_SUB+= NLS="@comment "
.endif
.include <bsd.port.mk>The next item on the to-do list is to arrange so that
the message catalog files are included in the packing list
conditionally. The Makefile part of
this task is already provided by the idiom. It is explained
in the section on advanced
pkg-plist practices. In a
nutshell, each occurrence of %%NLS%% in
pkg-plist will be replaced by
@comment if NLS is
disabled, or by a null string if NLS is enabled.
Consequently, the lines prefixed by
%%NLS%% will become mere comments in the
final packing list if NLS is off; otherwise the prefix will
be just left out. Then insert
%%NLS%% before each path to a message
catalog file in pkg-plist. For
example:%%NLS%%share/locale/fr/LC_MESSAGES/foobar.mo
%%NLS%%share/locale/no/LC_MESSAGES/foobar.moIn high complexity cases, more advanced techniques
may be needed, such as
dynamic packing list
generation.Handling Message Catalog DirectoriesThere is a point to note about installing message
catalog files. The target directories for them, which
reside under
LOCALBASE/share/locale,
must not be created and removed by a port. The most
popular languages have their respective directories listed
in
PORTSDIR/Templates/BSD.local.dist.
The directories for many other languages are governed by the
devel/gettext port.
Consult its pkg-plist and see whether
the port is going to install a message catalog file for a
unique language.Using PerlIf MASTER_SITES is set to
CPAN, the correct subdirectory is usually
selected automatically. If the default subdirectory is wrong,
CPAN/Module can be used to change it.
MASTER_SITES can also be set to the old
MASTER_SITE_PERL_CPAN, then the preferred
value of MASTER_SITE_SUBDIR is the
top-level hierarchy name. For example, the recommended value
for p5-Module-Name is
Module. The top-level hierarchy can be
examined at cpan.org.
This keeps the port working when the author of the module
changes.The exception to this rule is when the relevant directory
does not exist or the distfile does not exist in that
directory. In such case, using author's id as
MASTER_SITE_SUBDIR is allowed.
The CPAN:AUTHOR macro can be used, which will
be translated to the hashed author directory. For example,
CPAN:AUTHOR will be converted to
authors/id/A/AU/AUTHOR.When a port needs Perl support,
it must set USES=perl5 with the optional
USE_PERL5 described in the perl5 USES description.
Read-Only Variables for Ports That Use
PerlRead only variablesMeansPERLThe full path of the Perl 5 interpreter,
either in the system or installed from a port, but
without the version number. Use this when the software
needs the path to the Perl
interpreter. To replace
#!lines in scripts,
use USES=shebangfix.PERL_VERSIONThe full version of Perl installed (for example,
5.8.9).PERL_LEVELThe installed Perl version as
an integer of the form MNNNPP
(for example, 500809).PERL_ARCHWhere Perl stores architecture
dependent libraries. Defaults to
${ARCH}-freebsd.PERL_PORTName of the Perl port that is installed (for
example, perl5).SITE_PERLDirectory name where site specific
Perl packages go. This value is
added to PLIST_SUB.
Ports of Perl modules which do not have an official
website must link to cpan.org in
the WWW line of pkg-descr. The
preferred URL form is
http://search.cpan.org/dist/Module-Name/
(including the trailing slash).Do not use ${SITE_PERL} in dependency
declarations. Doing so assumes that
perl5.mk has been included, which is
not always true. Ports depending on this port will have
incorrect dependencies if this port's files move later in an
upgrade. The right way to declare Perl module dependencies
is shown in the example below.Perl Dependency Examplep5-IO-Tee>=0.64:devel/p5-IO-TeeFor Perl ports that install manual pages, the macro
PERL5_MAN3 and PERL5_MAN1
can be used
inside pkg-plist. For example,lib/perl5/5.14/man/man1/event.1.gz
lib/perl5/5.14/man/man3/AnyEvent::I3.3.gzcan be replaced with%%PERL5_MAN1%%/event.1.gz
%%PERL5_MAN3%%/AnyEvent::I3.3.gzThere are no
PERL5_MANx
macros for the
other sections (x in
2 and
4 to 9) because those
get installed in the regular directories.A Port Which Only Requires Perl to BuildAs the default USE_PERL5 value is build and run, set it
to:USES= perl5
USE_PERL5= buildA Port Which Also Requires Perl to PatchFrom time to time, using &man.sed.1; for patching is not
enough. When using &man.perl.1; is easier, use:USES= perl5
USE_PERL5= patch build runA Perl Module Which Needs
ExtUtils::MakeMaker to BuildMost Perl modules come with a
Makefile.PL configure script. In this
case, set:USES= perl5
USE_PERL5= configureA Perl Module Which Needs
Module::Build to BuildWhen a Perl module comes with a
Build.PL configure script, it can require
Module::Build, in which case,
setUSES= perl5
USE_PERL5= modbuildIf it instead requires
Module::Build::Tiny, setUSES= perl5
USE_PERL5= modbuildtinyUsing X11X.Org ComponentsThe X11 implementation available in The Ports Collection
is X.Org. If the application depends on X components, add
USES= xorg and set
USE_XORG to the list of required
components. A full list can be found in .The Mesa Project is an effort to provide free OpenGL
implementation. To specify a dependency on various
components of this project, use USES= gl
and USE_GL. See
for a full list of available
components. For backwards compatibility, the value of
yes maps to glu.USE_XORG ExampleUSES= gl xorg
USE_GL= glu
USE_XORG= xrender xft xkbfile xt xaw
Variables for Ports That Use XUSES= imakeThe port uses imake.XMKMFSet to the path of xmkmf if
not in the PATH. Defaults to
xmkmf -a.
Using X11-Related Variables# Use some X11 libraries
USES= xorg
USE_XORG= x11 xpmPorts That Require MotifIf the port requires a Motif library, define
USES= motif in the
Makefile. Default Motif implementation
is
x11-toolkits/open-motif.
Users can choose
x11-toolkits/lesstif
instead by setting WANT_LESSTIF
in their make.conf.MOTIFLIB will be set by
motif.mk to reference the
appropriate Motif library. Please patch the source of the
port to use ${MOTIFLIB} wherever
the Motif library is referenced in the original
Makefile or
Imakefile.There are two common cases:If the port refers to the Motif library as
-lXm in its
Makefile or
Imakefile, substitute
${MOTIFLIB} for it.If the port uses XmClientLibs in
its Imakefile, change it to
${MOTIFLIB} ${XTOOLLIB}
${XLIB}.Note that MOTIFLIB (usually) expands
to -L/usr/local/lib -lXm -lXp or
/usr/local/lib/libXm.a, so there is no
need to add -L or -l
in front.X11 FontsIf the port installs fonts for the X Window System, put
them in
LOCALBASE/lib/X11/fonts/local.Getting a Fake DISPLAY with XvfbSome applications require a working X11 display for
compilation to succeed. This poses a problem for machines
that operate headless. When this variable is used,
the build infrastructure will start the virtual framebuffer
X server. The working DISPLAY is then passed
to the build. See USES=display
for the possible arguments.USES= displayDesktop EntriesDesktop entries (a
Freedesktop standard) provide a way to
automatically adjust desktop features when a new program is
installed, without requiring user intervention. For
example, newly-installed programs automatically appear in
the application menus of compatible desktop environments.
Desktop entries originated in the
GNOME desktop environment, but
are now a standard and also work with
KDE and
Xfce. This bit of automation
provides a real benefit to the user, and desktop entries are
encouraged for applications which can be used in a desktop
environment.Using Predefined .desktop
FilesPorts that include predefined
*.desktop
must include those files in pkg-plist
and install them in the
$LOCALBASE/share/applications
directory. The INSTALL_DATA
macro is useful for installing these
files.Updating Desktop DatabaseIf a port has a MimeType entry in its
portname.desktop,
the desktop database must be updated after install and
deinstall. To do this, define USES=
desktop-file-utils.Creating Desktop Entries with
DESKTOP_ENTRIESDesktop entries can be easily created for applications
by using DESKTOP_ENTRIES. A
file named
name.desktop
will be created, installed, and added to
pkg-plist automatically. Syntax
is:DESKTOP_ENTRIES= "NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotifyThe list of possible categories is available on the
Freedesktop
website. StartupNotify
indicates whether the application is compatible with
startup notifications. These are
typically a graphic indicator like a clock that appear at
the mouse pointer, menu, or panel to give the user an
indication when a program is starting. A program that is
compatible with startup notifications clears the indicator
after it has started. Programs that are not compatible
with startup notifications would never clear the indicator
(potentially confusing and infuriating the user), and
must have StartupNotify set to
false so the indicator is not shown at
all.Example:DESKTOP_ENTRIES= "ToME" "Roguelike game based on JRR Tolkien's work" \
"${DATADIR}/xtra/graf/tome-128.png" \
"tome -v -g" "Application;Game;RolePlaying;" \
falseUsing GNOMEIntroductionThis chapter explains the GNOME
framework as used by ports. The framework can be loosely
divided into the base components, GNOME
desktop components, and a few special macros that simplify the
work of port maintainers.Using USE_GNOMEAdding this variable to the port allows the use of
the macros and components defined in
bsd.gnome.mk. The code in
bsd.gnome.mk adds the needed
build-time, run-time or library dependencies
or the handling of special files.
GNOME applications under &os; use the
USE_GNOME infrastructure. Include all the
needed components as a space-separated list. The
USE_GNOME components are divided into
these virtual lists: basic components, GNOME 3 components
and legacy components. If the port needs only GTK3 libraries,
this is the shortest way to define it:USE_GNOME= gtk30USE_GNOME components automatically
add the dependencies they need. Please see
for an exhaustive
list of all USE_GNOME components and which
other components they imply and their dependencies.Here is an example Makefile for a
GNOME port that uses many of the techniques outlined in this
document. Please use it as a guide for creating new
ports.# $FreeBSD$
PORTNAME= regexxer
DISTVERSION= 0.10
CATEGORIES= devel textproc gnome
MASTER_SITES= GNOME
MAINTAINER= kwm@FreeBSD.org
COMMENT= Interactive tool for performing search and replace operations
USES= gettext gmake pathfix pkgconfig tar:xz
GNU_CONFIGURE= yes
USE_GNOME= gnomeprefix intlhack gtksourceviewmm3
CPPFLAGS+= -I${LOCALBASE}/include
LDFLAGS+= -L${LOCALBASE}/lib
INSTALLS_ICONS= yes
GLIB_SCHEMAS= org.regexxer.gschema.xml
.include <bsd.port.mk>The USE_GNOME macro without any
arguments does not add any dependencies to the port.
USE_GNOME cannot be set after
bsd.port.pre.mk.VariablesThis section explains which macros are available and how
they are used. Like they are used in the above example. The
has a more in-depth
explanation. USE_GNOME has to be set for
these macros to be of use.INSTALLS_ICONSGTK+ ports which install
Freedesktop-style icons to
${LOCALBASE}/share/icons should use
this macro to ensure that the icons are cached and will
display correctly. The cache file is named
icon-theme.cache. Do not include
that file in pkg-plist. This macro
handles that automatically. This macro is not needed
for Qt, which uses an
internal method.GLIB_SCHEMASList of all the glib schema files the port installs.
The macro will add the files to the port plist and
handle the registration of these files on install and
deinstall.The glib schema files are written in
XML and end with the
gschema.xml extension. They are
installed in the
share/glib-2.0/schemas/ directory.
These schema files contain all application config values
with their default settings. The actual database used
by the applications is built by
glib-compile-schema, which is
run by the GLIB_SCHEMAS macro.GLIB_SCHEMAS=foo.gschema.xmlDo not add glib schemas to the
pkg-plist. If they are listed in
pkg-plist, they will not be
registered and the applications might not work
properly.GCONF_SCHEMASList all the gconf schema files. The macro will add
the schema files to the port plist and will handle their
registration on install and deinstall.GConf is the XML-based database
that virtually all GNOME applications use for storing
their settings. These files are installed into the
etc/gconf/schemas directory. This
database is defined by installed schema files that are
used to generate %gconf.xml key
files. For each schema file installed by the port,
there must be an entry in the
Makefile:GCONF_SCHEMAS=my_app.schemas my_app2.schemas my_app3.schemasGconf schemas are listed in the
GCONF_SCHEMAS macro rather than
pkg-plist. If they are listed in
pkg-plist, they will not be
registered and the applications might not work
properly.INSTALLS_OMFOpen Source Metadata Framework
(OMF) files are commonly used by
GNOME 2 applications. These files contain the
application help file information, and require special
processing by ScrollKeeper/rarian. To properly register
OMF files when installing GNOME
applications from packages, make sure that
omf files are listed in
pkg-plist and that the port
Makefile has
INSTALLS_OMF defined:INSTALLS_OMF=yesWhen set, bsd.gnome.mk
automatically scans pkg-plist and
adds appropriate @exec and
@unexec directives for each
.omf to track in the
OMF registration database.GNOME ComponentsFor further help with a GNOME port, look at some of the
existing
ports for examples. The
&os; GNOME
page has contact information if more help is
needed. The components are divided into GNOME components
that are currently in use and legacy components. If the
component supports argument, they are listed between
parenthesis in the description. The first is the default.
"Both" is shown if the component defaults to adding to both
build and run dependencies.
GNOME ComponentsComponentAssociated programDescriptionatkaccessibility/atkAccessibility toolkit (ATK)atkmmaccessibility/atkmmc++ bindings for atkcairographics/cairoVector graphics library with cross-device output
supportcairommgraphics/cairommc++ bindings for cairodconfdevel/dconfConfiguration database system
(both, build, run)evolutiondataserver3databases/evolution-data-serverData backends for the Evolution integrated
mail/PIM suitegdkpixbuf2graphics/gdk-pixbuf2Graphics library for GTK+glib20devel/glib20GNOME core library
glib20glibmmdevel/glibmmc++ bindings for glib20gnomecontrolcenter3sysutils/gnome-control-centerGNOME 3 Control Centergnomedesktop3x11/gnome-desktopGNOME 3 desktop UI librarygsoundaudio/gsoundGObject library for playing system sounds
(both, build, run)gtk-update-icon-cachegraphics/gtk-update-icon-cacheGtk-update-icon-cache utility from the Gtk+
toolkitgtk20x11-toolkits/gtk20Gtk+ 2 toolkitgtk30x11-toolkits/gtk30Gtk+ 3 toolkitgtkmm20x11-toolkits/gtkmm20c++ bindings 2.0 for the gtk20 toolkitgtkmm24x11-toolkits/gtkmm24c++ bindings 2.4 for the gtk20 toolkitgtkmm30x11-toolkits/gtkmm30c++ bindings 3.0 for the gtk30 toolkitgtksourceview2x11-toolkits/gtksourceview2Widget that adds syntax highlighting to
GtkTextViewgtksourceview3x11-toolkits/gtksourceview3Text widget that adds syntax highlighting to
the GtkTextView widgetgtksourceviewmm3x11-toolkits/gtksourceviewmm3c++ bindings for the gtksourceview3 librarygvfsdevel/gvfsGNOME virtual file systemintltooltextproc/intltoolTool for internationalization (also see
intlhack)introspectiondevel/gobject-introspectionBasic introspection bindings and tools to
generate introspection bindings. Most of the time
:build is enough, :both/:run is only need for
applications that use introspection bindings.
(both, build, run)libgda5databases/libgda5Provides uniform access to different kinds of
data sourceslibgda5-uidatabases/libgda5-uiUI library from the libgda5 librarylibgdamm5databases/libgdamm5c++ bindings for the libgda5 librarylibgsfdevel/libgsfExtensible I/O abstraction for dealing with
structured file formatslibrsvg2graphics/librsvg2Library for parsing and rendering SVG
vector-graphic fileslibsigc++20devel/libsigc++20Callback Framework for C++libxml++26textproc/libxml++26c++ bindings for the libxml2 librarylibxml2textproc/libxml2XML parser library (both, build, run)libxslttextproc/libxsltXSLT C library (both, build, run)metacityx11-wm/metacityWindow manager from GNOMEnautilus3x11-fm/nautilusGNOME file managerpangox11-toolkits/pangoOpen-source framework for the layout and
rendering of i18n textpangommx11-toolkits/pangommc++ bindings for the pango librarypy3gobject3devel/py3-gobject3Python 3, GObject 3.0 bindingspygobject3devel/py-gobject3Python 2, GObject 3.0 bindingsvte3x11-toolkits/vte3Terminal widget with improved accessibility and
I18N support
GNOME Macro ComponentsComponentDescriptiongnomeprefixSupply configure with
some default locations.intlhackSame as intltool, but patches to make sure
share/locale/ is used. Please
only use when intltool alone is
not enough.referencehackThis macro is there to help splitting of the API or
reference documentation into its own port.
GNOME Legacy ComponentsComponentAssociated programDescriptionatspiaccessibility/at-spiAssistive Technology Service Provider
Interfaceesoundaudio/esoundEnlightenment sound packagegal2x11-toolkits/gal2Collection of widgets taken from GNOME 2
gnumericgconf2devel/gconf2Configuration database system for GNOME 2gconfmm26devel/gconfmm26c++ bindings for gconf2gdkpixbufgraphics/gdk-pixbufGraphics library for GTK+glib12devel/glib12glib 1.2 core librarygnomedocutilstextproc/gnome-doc-utilsGNOME doc utilsgnomemimedatamisc/gnome-mime-dataMIME and Application database for GNOME 2gnomesharp20x11-toolkits/gnome-sharp20GNOME 2 interfaces for the .NET runtimegnomespeechaccessibility/gnome-speechGNOME 2 text-to-speech APIgnomevfs2devel/gnome-vfsGNOME 2 Virtual File Systemgtk12x11-toolkits/gtk12Gtk+ 1.2 toolkitgtkhtml3www/gtkhtml3Lightweight HTML rendering/printing/editing
enginegtkhtml4www/gtkhtml4Lightweight HTML rendering/printing/editing
enginegtksharp20x11-toolkits/gtk-sharp20GTK+ and GNOME 2 interfaces for the .NET
runtimegtksourceviewx11-toolkits/gtksourceviewWidget that adds syntax highlighting to
GtkTextViewlibartgpl2graphics/libart_lgplLibrary for high-performance 2D graphicslibbonobodevel/libbonoboComponent and compound document system for
GNOME 2libbonobouix11-toolkits/libbonobouiGUI frontend to the libbonobo component of
GNOME 2libgda4databases/libgda4Provides uniform access to different kinds of
data sourceslibglade2devel/libglade2GNOME 2 glade librarylibgnomex11/libgnomeLibraries for GNOME 2, a GNU desktop
environmentlibgnomecanvasgraphics/libgnomecanvasGraphics library for GNOME 2libgnomekbdx11/libgnomekbdGNOME 2 keyboard shared librarylibgnomeprintprint/libgnomeprintGnome 2 print support librarylibgnomeprintuix11-toolkits/libgnomeprintuiGnome 2 print support librarylibgnomeuix11-toolkits/libgnomeuiLibraries for the GNOME 2 GUI, a GNU desktop
environmentlibgtkhtmlwww/libgtkhtmlLightweight HTML rendering/printing/editing
enginelibgtksourceviewmmx11-toolkits/libgtksourceviewmmc++ binding of GtkSourceViewlibidldevel/libIDLLibrary for creating trees of CORBA IDL
filelibsigc++12devel/libsigc++12Callback Framework for C++libwnckx11-toolkits/libwnckLibrary used for writing pagers and
taskslistslibwnck3x11-toolkits/libwnck3Library used for writing pagers and
taskslistsorbit2devel/ORBit2High-performance CORBA ORB with support for the
C languagepygnome2x11-toolkits/py-gnome2Python bindings for GNOME 2pygobjectdevel/py-gobjectPython 2, GObject 2.0 bindingspygtk2x11-toolkits/py-gtk2Set of Python bindings for GTK+pygtksourceviewx11-toolkits/py-gtksourceviewPython bindings for GtkSourceView 2vtex11-toolkits/vteTerminal widget with improved accessibility and
I18N support
Deprecated Components: Do Not UseComponentDescriptionpangox-compatpangox-compat has been
deprecated and split off from the
pango package.
Using QtFor ports that are part of Qt itself, see .Ports That Require QtThe Ports Collection provides support for Qt 5 with
USES+=qt:5. Set USE_QT
to the list of required Qt components (libraries, tools,
plugins).The Qt framework exports a number of variables which can
be used by ports, some of them listed below:
Variables Provided to Ports That Use QtQMAKEFull path to qmake
binary.LRELEASEFull path to lrelease
utility.MOCFull path to moc.RCCFull path to rcc.UICFull path to uic.QT_INCDIRQt include directory.QT_LIBDIRQt libraries path.QT_PLUGINDIRQt plugins path.
Component SelectionIndividual Qt tool and library dependencies must be
specified in USE_QT.
Every component can be suffixed with
_build or _run, the
suffix indicating whether the dependency on the component is
at buildtime or runtime. If unsuffixed, the component will be
depended on at both build- and runtime. Usually, library
components are specified unsuffixed, tool components
are mostly specified with the _build suffix
and plugin components are specified with the
_run suffix. The most commonly used
components are listed below (all available components are
listed in _USE_QT_ALL, and
_USE_QT5_ONLY in
/usr/ports/Mk/Uses/qt.mk):
Available Qt Library ComponentsNameDescription3dQt3D moduleassistantQt 5 documentation browsercanvas3dQt canvas3d modulechartsQt 5 charts moduleconcurrentQt multi-threading moduleconnectivityQt connectivity (Bluetooth/NFC) modulecoreQt core non-graphical moduledatavis3dQt 5 3D data visualization moduledbusQt D-Bus inter-process communication
moduledeclarativeQt declarative framework for dynamic user
interfacesdesignerQt 5 graphical user interface designerdiagTool for reporting diagnostic information about
Qt and its environmentdocQt 5 documentationexamplesQt 5 examples sourcecodegamepadQt 5 Gamepad ModulegraphicaleffectsQt Quick graphical effectsguiQt graphical user interface modulehelpQt online help integration modulel10nQt localized messageslinguistQt 5 translation toollocationQt location modulemultimediaQt audio, video, radio and camera support
modulenetworkQt network modulenetworkauthQt network auth moduleopenglQt 5-compatible OpenGL support modulepathsCommand line client to QStandardPathsphonon4KDE multimedia frameworkpixeltoolQt 5 screen magnifierplugininfoQt5 plugin metadata dumperprintsupportQt print support moduleqdbusQt command-line interface to D-BusqdbusviewerQt 5 graphical interface to D-BusqdocQt documentation generatorqdoc-dataQDoc configuration filesqevQt QWidget events introspection toolqmakeQt Makefile generatorquickcontrolsSet of controls for building complete interfaces
in Qt Quickquickcontrols2Set of controls for building complete interfaces
in Qt QuickremoteobjectsQt5 SXCML modulescriptQt 4-compatible scripting modulescripttoolsQt Script additional componentsscxmlQt5 SXCML modulesensorsQt sensors moduleserialbusQt functions to access industrial bus
systemsserialportQt functions to access serial portsspeechAccessibilty features for Qt5sqlQt SQL database integration modulesql-ibaseQt InterBase/Firebird database pluginsql-mysqlQt MySQL database pluginsql-odbcQt Open Database Connectivity pluginsql-pgsqlQt PostgreSQL database pluginsql-sqlite2Qt SQLite 2 database pluginsql-sqlite3Qt SQLite 3 database pluginsql-tdsQt TDS Database Connectivity database
pluginsvgQt SVG support moduletestlibQt unit testing moduleuipluginCustom Qt widget plugin interface for Qt
DesigneruitoolsQt Designer UI forms support modulevirtualkeyboardQt 5 Virtual Keyboard ModulewaylandQt5 wrapper for WaylandwebchannelQt 5 library for integration of C++/QML with
HTML/js clientswebengineQt 5 library to render web contentwebkitQtWebKit with a more modern WebKit code
basewebsocketsQt implementation of WebSocket protocolwebsockets-qmlQt implementation of WebSocket protocol (QML
bindings)webviewQt component for displaying web contentwidgetsQt C++ widgets modulex11extrasQt platform-specific features for X11-based
systemsxmlQt SAX and DOM implementationsxmlpatternsQt support for XPath, XQuery, XSLT and XML
Schema
To determine the libraries an application
depends on, run ldd on the main
executable after a successful compilation.
Available Qt Tool ComponentsNameDescriptionbuildtoolsbuild tools (moc,
rcc), needed for almost every
Qt application.linguisttoolslocalization tools: lrelease,
lupdateqmakeMakefile generator/build utility
Available Qt Plugin ComponentsNameDescriptionimageformatsplugins for TGA, TIFF, and MNG
image formats
Selecting Qt 5 ComponentsIn this example, the ported application uses the Qt 5
graphical user interface library, the Qt 5 core library,
all of the Qt 5 code generation tools and Qt 5's Makefile
generator. Since the gui library
implies a dependency on the core library,
core does not need to be specified.
The Qt 5 code generation tools moc,
uic and rcc, as well
as the Makefile generator qmake are
only needed at buildtime, thus they are specified with the
_build suffix:USES= qt:5
USE_QT= gui buildtools_build qmake_buildUsing qmakeIf the application provides a
qmake project file
(*.pro), define
USES= qmake along with
USE_QT. USES= qmake
already implies a build dependency on qmake, therefore the
qmake component can be omitted from
USE_QT. Similar to CMake,
qmake supports out-of-source
builds, which can be enabled by specifying the
outsource argument (see USES= qmake
example). Also see .
Possible Arguments for
USES= qmakeVariableDescriptionno_configureDo not add the configure target. This is
implied by HAS_CONFIGURE=yes
and GNU_CONFIGURE=yes.
It is required when the build only needs the
environment setup from
USES= qmake, but otherwise runs
qmake on its own.no_envSuppress modification of the configure and make
environments. It is only required when
qmake is used to configure the
software and the build fails to understand the
environment setup by
USES= qmake.norecursiveDo not pass the -recursive
argument to qmake.outsourcePerform an out-of-source build.
Variables for Ports That Use
qmakeVariableDescriptionQMAKE_ARGSPort specific qmake
flags to be passed to the qmake
binary.QMAKE_ENVEnvironment variables to be set for the
qmake binary. The default is
${CONFIGURE_ENV}.QMAKE_SOURCE_PATHPath to qmake project files
(.pro). The default is
${WRKSRC} if an
out-of-source build is requested, empty
otherwise.
When using USES= qmake, these
settings are deployed:CONFIGURE_ARGS+= --with-qt-includes=${QT_INCDIR} \
--with-qt-libraries=${QT_LIBDIR} \
--with-extra-libs=${LOCALBASE}/lib \
--with-extra-includes=${LOCALBASE}/include
CONFIGURE_ENV+= QTDIR="${QT_PREFIX}" QMAKE="${QMAKE}" \
MOC="${MOC}" RCC="${RCC}" UIC="${UIC}" \
QMAKESPEC="${QMAKESPEC}"
PLIST_SUB+= QT_INCDIR=${QT_INCDIR_REL} \
QT_LIBDIR=${QT_LIBDIR_REL} \
QT_PLUGINDIR=${QT_PLUGINDIR_REL}Some configure scripts do not support the arguments above.
To suppress modification of CONFIGURE_ENV
and CONFIGURE_ARGS, set
USES= qmake:no_env.USES= qmake ExampleThis snippet demonstrates the use of
qmake for a Qt 5 port:USES= qmake:outsource qt:5
USE_QT= buildtools_buildQt applications are often written to be cross-platform
and often X11/Unix is not the platform they are developed
on, which in turn leads to certain loose ends,
like:Missing additional include
paths. Many applications come with
system tray icon support, but neglect to look for
includes and/or libraries in the X11 directories. To add
directories to qmake's
include and library search paths via the command
line, use:QMAKE_ARGS+= INCLUDEPATH+=${LOCALBASE}/include \
LIBS+=-L${LOCALBASE}/libBogus installation paths.
Sometimes data such as icons or .desktop files are by
default installed into directories which are not scanned
by XDG-compatible applications.
editors/texmaker is
an example for this - look at
patch-texmaker.pro in the
files directory of that port for a
template on how to remedy this directly in the
qmake project file.Using KDEKDE Variable DefinitionsIf the application depends on KDE, set
USES+=kde:5 and
USE_KDE to the list of required
components. _build and
_run suffixes can be used to force
components dependency type (for example,
baseapps_run). If no suffix is set, a
default dependency type will be used. To force both types,
add the component twice with both suffixes (for example,
ecm_build ecm_run). Available components
are listed below (up-to-date components are also listed in
/usr/ports/Mk/Uses/kde.mk):
Available KDE ComponentsNameDescriptionactivitiesKF5 runtime and library to organize work in
separate activitiesactivities-statsKF5 statistics for activitiesactivitymanagerdSystem service to manage user's activities, track
the usage patternsakonadiStorage server for KDE-PimakonadicalendarAkonadi Calendar IntegrationakonadiconsoleAkonadi management and debugging consoleakonadicontactsLibraries and daemons to implement Contact
Management in AkonadiakonadiimportwizardImport data from other mail clients to
KMailakonadimimeLibraries and daemons to implement basic email
handlingakonadinotesKDE library for accessing mail storages in MBox
formatakonadisearchLibraries and daemons to implement searching in
AkonadiakregatorA Feed Reader by KDEalarmcalendarKDE API for KAlarm alarmsapidoxKF5 API Documentation ToolsarchiveKF5 library that provides classes for handling
archive formatsatticaOpen Collaboration Services API library KDE5
versionattica5Open Collaboration Services API library KDE5
versionauthKF5 abstraction to system policy and
authentication featuresbalooKF5 Framework for searching and managing user
metadatabaloo-widgetsBalooWidgets librarybaloo5KF5 Framework for searching and managing user
metadatablogKDE API for weblogging accessbookmarksKF5 library for bookmarks and the XBEL
formatbreezePlasma5 artwork, styles and assets for the Breeze
visual stylebreeze-gtkPlasma5 Breeze visual style for Gtkbreeze-iconsBreeze icon theme for KDEcalendarcoreKDE calendar access librarycalendarsupportCalendar support libraries for KDEPimcalendarutilsKDE utility and user interface functions for
accessing calendarcodecsKF5 library for string manipulationcompletionKF5 text completion helpers and widgetsconfigKF5 widgets for configuration dialogsconfigwidgetsKF5 widgets for configuration dialogscontactsKDE api to manage contact informationcoreaddonsKF5 addons to QtCorecrashKF5 library to handle crash analysis and bug
report from appsdbusaddonsKF5 addons to QtDBusdecorationPlasma5 library to create window
decorationsdesignerpluginKF5 integration of Frameworks widgets in Qt
Designer/CreatordiscoverPlasma5 package management toolsdnssdKF5 abstraction to system DNSSD featuresdoctoolsKF5 documentation generation from docbookdrkonqiPlasma5 crash handlerecmExtra modules and scripts for CMakeemoticonsKF5 library to convert emoticonseventviewsEvent view libriares for KDEPimfilemetadataKF5 library for extracting file metadataframeworkintegrationKF5 workspace and cross-framework integration
pluginsgapiKDE based library to access google
servicesglobalaccelKF5 library to add support for global workspace
shortcutsgrantlee-editorEditor for Grantlee themesgrantleethemeKDE PIM grantleethemegravatarLibrary for gravatar supportguiaddonsKF5 addons to QtGuiholidaysKDE library for calendar holidayshotkeysPlasma5 library for hotkeysi18nKF5 advanced internationalization
frameworkiconthemesKF5 library for handling icons in
applicationsidentitymanagementKDE pim identitiesidletimeKF5 library for monitoring user activityimapKDE API for IMAP supportincidenceeditorIncidence editor libriares for KDEPiminfocenterPlasma5 utility providing system
informationinitKF5 process launcher to speed up launching KDE
applicationsitemmodelsKF5 models for Qt Model/View systemitemviewsKF5 widget addons for Qt Model/ViewjobwidgetsKF5 widgets for tracking KJob instancejsKF5 library providing an ECMAScript
interpreterjsembedKF5 library for binding JavaScript objects to
QObjectskaddressbookKDE contact managerkalarmPersonal alarm schedulerkalarmPersonal alarm schedulerkateBasic editor framework for the KDE systemkcmutilsKF5 utilities for working with KCModuleskde-cli-toolsPlasma5 non-interactive system toolskde-gtk-configPlasma5 GTK2 and GTK3 configuratorkdeclarativeKF5 library providing integration of QML and KDE
FrameworkskdedKF5 extensible daemon for providing system level
serviceskdelibs4supportKF5 porting aid from KDELibs4kdepim-addonsKDE PIM addonskdepim-apps-libsKDE PIM mail related librarieskdepim-runtime5KDE PIM tools and serviceskdeplasma-addonsPlasma5 addons to improve the Plasma
experiencekdesuKF5 integration with su for elevated
privilegeskdewebkitKF5 library providing integration of
QtWebKitkgamma5Plasma5 monitor's gamma settingskhtmlKF5 KTHML rendering enginekimageformatsKF5 library providing support for additional
image formatskioKF5 resource and network access
abstractionkirigami2QtQuick based components setkitineraryData Model and Extraction System for Travel
Reservation informationkmailKDE mail clientkmailKDE mail clientkmail-account-wizardKDE mail account wizardkmenueditPlasma5 menu editorknotesPopup noteskontactKDE Personal Information ManagerkontactKDE Personal Information ManagerkontactinterfaceKDE glue for embedding KParts into
KontactkorganizerCalendar and scheduling ProgramkpimdavA DAV protocol implementation with KJobskpkpassLibrary to deal with Apple Wallet pass
fileskrossKF5 multi-language application scriptingkscreenPlasma5 screen management librarykscreenlockerPlasma5 secure lock screen architectureksmtpJob-based library to send email through an SMTP
serverksshaskpassPlasma5 ssh-add frontendksysguardPlasma5 utility to track and control the running
processeskwallet-pamPlasma5 KWallet PAM Integrationkwayland-integrationIntegration plugins for a Wayland-based
desktopkwinPlasma5 window managerkwritedPlasma5 daemon listening for wall and write
messagesldapLDAP access API for KDElibkcddbKDE CDDB librarylibkcompactdiscKDE library for interfacing with audio
CDslibkdcrawLibRaw interface for KDElibkdegamesLibraries used by KDE gameslibkdepimKDE PIM LibrarieslibkeduvocdocumentLibrary for reading and writing vocabulary
fileslibkexiv2Exiv2 library interface for KDElibkipiKDE Image Plugin InterfacelibkleoCertificate manager for KDElibksaneSANE library interface for KDElibkscreenPlasma5 screen management librarylibksieveSieve libriares for KDEPimlibksysguardPlasma5 library to track and control running
processesmailcommonCommon libriares for KDEPimmailimporterImport mbox files to KMailmailtransportKDE library to managing mail transportmarbleVirtual globe and world atlas for KDEmboxKDE library for accessing mail storages in MBox
formatmbox-importerImport mbox files to KMailmediaplayerKF5 plugin interface for media player
featuresmessagelibLibrary for handling messagesmilouPlasma5 Plasmoid for searchmimeLibrary for handling MIME datanewstuffKF5 library for downloading application assets
from the networknotificationsKF5 abstraction for system notificationsnotifyconfigKF5 configuration system for KNotifyokularKDE universal document vieweroxygenPlasma5 Oxygen styleoxygen-icons5The Oxygen icon theme for KDEpackageKF5 library to load and install packagespartsKF5 document centric plugin systempeopleKF5 library providing access to contactspim-data-exporterImport and export KDE PIM settingspimcommonCommon libriares for KDEPimpimtexteditKDE library for PIM-specific text editing
utilitiesplasma-browser-integrationPlasma5 components to integrate browsers into the
desktopplasma-desktopPlasma5 plasma desktopplasma-frameworkKF5 plugin based UI runtime used to write user
interfacesplasma-integrationQt Platform Theme integration plugins for the
Plasma workspacesplasma-paPlasma5 Plasma pulse audio mixerplasma-sdkPlasma5 applications useful for Plasma
developmentplasma-workspacePlasma5 Plasma workspaceplasma-workspace-wallpapersPlasma5 wallpapersplottingKF5 lightweight plotting frameworkpolkit-kde-agent-1Plasma5 daemon providing a polkit authentication
UIpowerdevilPlasma5 tool to manage the power consumption
settingsprisonAPI to produce barcodesptyKF5 pty abstractionpurposeOffers available actions for a specific
purposeqqc2-desktop-styleQt QuickControl2 style for KDErunnerKF5 parallelized query systemserviceKF5 advanced plugin and service
introspectionsolidKF5 hardware integration and detectionsonnetKF5 plugin-based spell checking librarysyndicationKDE RSS feed handling librarysyntaxhighlightingKF5 syntax highlighting engine for structured
text and codesystemsettingsPlasma5 system settingstexteditorKF5 advanced embeddable text editortextwidgetsKF5 advanced text editing widgetsthreadweaverKF5 addons to QtDBustnefKDE API for the handling of TNEF dataunitconversionKF5 library for unit conversionuser-managerPlasma5 user managerwalletKF5 secure and unified container for user
passwordswaylandKF5 Client and Server library wrapper for the
Wayland librarieswidgetsaddonsKF5 addons to QtWidgetswindowsystemKF5 library for access to the windowing
systemxmlguiKF5 user configurable main windowsxmlrpcclientKF5 interaction with XMLRPC services
USE_KDE ExampleThis is a simple example for a KDE port.
USES= cmake instructs the
port to utilize CMake, a
configuration tool widely used by KDE projects (see
for detailed usage).
USE_KDE brings dependency on KDE
libraries. Required KDE components and other dependencies
can be determined through the configure log.
USE_KDE does not imply
USE_QT. If a port requires some
Qt components, specify them in
USE_QT.USES= cmake kde:5 qt:5
USE_KDE= ecm
USE_QT= core buildtools_build qmake_buildUsing LXQtApplications depending on LXQt should set
USES+= lxqt and set
USE_LXQT
to the list of required components from the table below
Available LXQt ComponentsNameDescriptionbuildtoolsHelpers for additional CMake moduleslibfmqtLibfm Qt bindingslxqtLXQt core libraryqtxdgQt implementation of freedesktop.org
XDG specifications
USE_LXQT ExampleThis is a simple example,
USE_LXQT adds a dependency on
LXQt libraries. Required LXQt components and
other dependencies can be determined from the
configure log.USES= cmake lxqt qt:5 tar:xz
USE_QT= core dbus widgets buildtools_build qmake_build
USE_LXQT= buildtools libfmqtUsing JavaVariable DefinitionsIf the port needs a Java™ Development Kit
(JDK™) to either build, run or even
extract the distfile, then define
USE_JAVA.There are several JDKs in the ports
collection, from various vendors, and in several versions. If
the port must use a particular version, specify it using the
JAVA_VERSION variable.
The most current version is
java/openjdk8, with
java/openjdk6 and
java/openjdk7 also
available.
Variables Which May be Set by Ports That Use
JavaVariableMeansUSE_JAVADefine for the remaining variables
to have any effect.JAVA_VERSIONList of space-separated suitable Java versions
for the port. An optional "+"
allows specifying a range of versions (allowed
values:
1.5[+] 1.6[+] 1.7[+]).JAVA_OSList of space-separated suitable
JDK port operating systems for the
port (allowed values:
native linux).JAVA_VENDORList of space-separated suitable
JDK port vendors for the port
(allowed values:
freebsd bsdjava sun
openjdk).JAVA_BUILDWhen set, add the selected JDK
port to the build dependencies.JAVA_RUNWhen set, add the selected JDK
port to the run dependencies.JAVA_EXTRACTWhen set, add the selected JDK
port to the extract dependencies.
Below is the list of all settings a port will receive
after setting USE_JAVA:
Variables Provided to Ports That Use JavaVariableValueJAVA_PORTThe name of the JDK port (for
example, java/openjdk6).JAVA_PORT_VERSIONThe full version of the JDK
port (for example, 1.6.0). Only
the first two digits of this version number are
needed, use
${JAVA_PORT_VERSION:C/^([0-9])\.([0-9])(.*)$/\1.\2/}.JAVA_PORT_OSThe operating system used by the
JDK port (for example,
'native').JAVA_PORT_VENDORThe vendor of the JDK port
(for example, 'openjdk').JAVA_PORT_OS_DESCRIPTIONDescription of the operating system used by the
JDK port (for example,
'Native').JAVA_PORT_VENDOR_DESCRIPTIONDescription of the vendor of the
JDK port (for example,
'OpenJDK BSD Porting
Team').JAVA_HOMEPath to the installation directory of the
JDK (for example,
'/usr/local/openjdk6').JAVACPath to the Java compiler to use (for example,
'/usr/local/openjdk6/bin/javac').JARPath to the jar tool to use
(for example,
'/usr/local/openjdk6/bin/jar'
or
'/usr/local/bin/fastjar').APPLETVIEWERPath to the appletviewer
utility (for example,
'/usr/local/openjdk6/bin/appletviewer').JAVAPath to the java executable.
Use this for executing Java programs (for example,
'/usr/local/openjdk6/bin/java').JAVADOCPath to the javadoc utility
program.JAVAHPath to the javah
program.JAVAPPath to the javap
program.JAVA_KEYTOOLPath to the keytool utility
program.JAVA_N2APath to the native2ascii
tool.JAVA_POLICYTOOLPath to the policytool
program.JAVA_SERIALVERPath to the serialver
utility program.RMICPath to the RMI stub/skeleton generator,
rmic.RMIREGISTRYPath to the RMI registry program,
rmiregistry.RMIDPath to the RMI daemon program
rmid.JAVA_CLASSESPath to the archive that contains the
JDK class files,
${JAVA_HOME}/jre/lib/rt.jar.
Use the java-debug make
target to get information for debugging the port. It will
display the value of many of the previously listed
variables.Additionally, these constants are defined so all
Java ports may be installed in a consistent way:
Constants Defined for Ports That Use JavaConstantValueJAVASHAREDIRThe base directory for everything related to
Java. Default:
${PREFIX}/share/java.JAVAJARDIRThe directory where JAR files is
installed. Default:
${JAVASHAREDIR}/classes.JAVALIBDIRThe directory where JAR files installed by
other ports are located. Default:
${LOCALBASE}/share/java/classes.
The related entries are defined in both
PLIST_SUB (documented in
) and
SUB_LIST.Building with AntWhen the port is to be built using Apache Ant, it has to
define USE_ANT. Ant is thus considered to
be the sub-make command. When no
do-build target is defined by the
port, a default one will be set that runs Ant according to
MAKE_ENV, MAKE_ARGS and
ALL_TARGET. This is similar to the
USES= gmake mechanism, which is documented
in .Best PracticesWhen porting a Java library, the port has to install
the JAR file(s) in ${JAVAJARDIR}, and
everything else under
${JAVASHAREDIR}/${PORTNAME} (except for
the documentation, see below). To reduce the packing file
size, reference the JAR file(s) directly in the
Makefile. Use this statement (where
myport.jar is
the name of the JAR file installed as part of the
port):PLIST_FILES+= ${JAVAJARDIR}/myport.jarWhen porting a Java application, the port usually
installs everything under a single directory (including its
JAR dependencies). The use of
${JAVASHAREDIR}/${PORTNAME} is strongly
encouraged in this regard. It is up the porter to decide
whether the port installs the additional JAR
dependencies under this directory or uses the
already installed ones (from
${JAVAJARDIR}).When porting a &java; application that requires an
application server such as
www/tomcat7 to run the
service, it is quite common for a vendor to distribute a
.war. A .war
is a Web application ARchive and is extracted when
called by the application. Avoid adding a
.war
to pkg-plist.
It is not considered best practice. An application server
will expand war archive, but not
clean it up properly if the port is removed. A more
desirable way of working with this file is to extract the
archive, then install the files, and lastly add these files
to pkg-plist.TOMCATDIR= ${LOCALBASE}/apache-tomcat-7.0
WEBAPPDIR= myapplication
post-extract:
@${MKDIR} ${WRKDIR}/${PORTDIRNAME}
@${TAR} xf ${WRKDIR}/myapplication.war -C ${WRKDIR}/${PORTDIRNAME}
do-install:
cd ${WRKDIR} && \
${INSTALL} -d -o ${WWWOWN} -g ${WWWGRP} ${TOMCATDIR}/webapps/${PORTDIRNAME}
cd ${WRKDIR}/${PORTDIRNAME} && ${COPYTREE_SHARE} \* ${WEBAPPDIR}/${PORTDIRNAME}Regardless of the type of port (library or
application), the additional documentation is installed in the
same location as
for any other port. The Javadoc tool is known to produce a
different set of files depending on the version of the
JDK that is used. For ports that do not
enforce the use of a particular JDK, it is
therefore a complex task to specify the packing list
(pkg-plist). This is one reason why
porters are strongly encouraged to use
PORTDOCS. Moreover, even if the set of
files that will be generated by javadoc can
be predicted, the size of the resulting
pkg-plist advocates for the use of
PORTDOCS.The default value for DATADIR is
${PREFIX}/share/${PORTNAME}. It is a
good idea to override DATADIR to
${JAVASHAREDIR}/${PORTNAME} for Java
ports. Indeed, DATADIR is automatically
added to PLIST_SUB (documented in
) so use
%%DATADIR%% directly in
pkg-plist.As for the choice of building Java ports from source or
directly installing them from a binary distribution, there
is no defined policy at the time of writing. However,
people from the
&os; Java
Project encourage porters to have their ports
built from source whenever it is a trivial task.All the features that have been presented in this
section are implemented in bsd.java.mk.
If the port needs more sophisticated
Java support, please first have a look at the bsd.java.mk
Subversion log as it
usually takes some time to document the latest features.
Then, if the needed support that is lacking would be
beneficial to many other Java ports, feel free to discuss it
on the &a.java;.Although there is a java category for
PRs, it refers to the JDK porting effort
from the &os; Java project. Therefore, submit the Java port
in the ports category as for any other
port, unless the issue is related to either a
JDK implementation or
bsd.java.mk.Similarly, there is a defined policy regarding the
CATEGORIES of a Java port, which is
detailed in .Web Applications, Apache and PHPApache
Variables for Ports That Use ApacheUSE_APACHEThe port requires Apache. Possible values:
yes (gets any version),
22, 24,
22-24, 22+,
etc. The default APACHE version is
22. More details are available
in ports/Mk/bsd.apache.mk and
at wiki.freebsd.org/Apache/.APXSFull path to the apxs
binary. Can be overridden in the port.HTTPDFull path to the httpd
binary. Can be overridden in the port.APACHE_VERSIONThe version of present Apache installation
(read-only variable). This variable is only
available after inclusion of
bsd.port.pre.mk. Possible
values: 22,
24.APACHEMODDIRDirectory for Apache modules. This variable is
automatically expanded in
pkg-plist.APACHEINCLUDEDIRDirectory for Apache headers. This variable is
automatically expanded in
pkg-plist.APACHEETCDIRDirectory for Apache configuration files. This
variable is automatically expanded in
pkg-plist.
Useful Variables for Porting Apache ModulesMODULENAMEName of the module. Default value is
PORTNAME. Example:
mod_helloSHORTMODNAMEShort name of the module. Automatically
derived from MODULENAME, but can
be overridden. Example:
helloAP_FAST_BUILDUse apxs to compile and
install the module.AP_GENPLISTAlso automatically creates a
pkg-plist.AP_INCAdds a directory to a header search path during
compilation.AP_LIBAdds a directory to a library search path
during compilation.AP_EXTRASAdditional flags to pass to
apxs.
Web ApplicationsWeb applications must be installed into
PREFIX/www/appname.
This path is available both in
Makefile and in
pkg-plist as WWWDIR,
and the path relative to PREFIX is
available in Makefile as
WWWDIR_REL.The user and group of web server process are available
as WWWOWN and WWWGRP,
in case the ownership of some files needs to be changed. The
default values of both are www. Use
WWWOWN?= myuser and WWWGRP?=
mygroup if the port needs different values. This
allows the user to override them easily.Use WWWOWN and
WWWGRP sparingly. Remember that every
file the web server can write to is a security risk waiting
to happen.Do not depend on Apache unless the web app explicitly
needs Apache. Respect that users may wish to run a web
application on a web server other than
Apache.PHPPHP web applications declare
their dependency on it with USES=php. See
for more information.PEAR ModulesPorting PEAR modules is a very simple process.Add USES=pear to the port's
Makefile. The framework will install the
relevant files in the right places and automatically generate
the plist at install time.Example Makefile for PEAR ClassPORTNAME= Date
DISTVERSION= 1.4.3
CATEGORIES= devel www pear
MAINTAINER= example@domain.com
COMMENT= PEAR Date and Time Zone Classes
USES= pear
.include <bsd.port.mk>PEAR modules will
automatically be flavorized using PHP
flavors.If a non default PEAR_CHANNEL is
used, the build and run-time dependencies will automatically
be added.PEAR modules do not need to defined
PKGNAMESUFFIX it is automatically filled
in using PEAR_PKGNAMEPREFIX. If a port
needs to add to PKGNAMEPREFIX, it must
also use PEAR_PKGNAMEPREFIX to
differentiate between different flavors.Horde ModulesIn the same way, porting
Horde modules is a simple
process.Add USES=horde to the port's
Makefile. The framework will install
the relevant files in the right places and automatically
generate the plist at install time.The USE_HORDE_BUILD and
USE_HORDE_RUN variables can be used to
add buildtime and runtime dependencies on other
Horde modules. See
Mk/Uses/horde.mk for a complete list of
available modules.Example Makefile for Horde
ModulePORTNAME= Horde_Core
DISTVERSION= 2.14.0
CATEGORIES= devel www pear
MAINTAINER= horde@FreeBSD.org
COMMENT= Horde Core Framework libraries
OPTIONS_DEFINE= KOLAB SOCKETS
KOLAB_DESC= Enable Kolab server support
SOCKETS_DESC= Depend on sockets PHP extension
USES= horde
USE_PHP= session
USE_HORDE_BUILD= Horde_Role
USE_HORDE_RUN= Horde_Role Horde_History Horde_Pack \
Horde_Text_Filter Horde_View
KOLAB_USE= HORDE_RUN=Horde_Kolab_Server,Horde_Kolab_Session
SOCKETS_USE= PHP=sockets
.include <bsd.port.mk>As Horde modules are also
PEAR modules they will also
automatically be flavorized using PHP
flavors.Using PythonThe Ports Collection supports parallel installation of
multiple Python versions. Ports must use a
correct python interpreter, according to
the user-settable PYTHON_VERSION.
Most prominently, this means replacing the path to
python executable in scripts with the value
of PYTHON_CMD.Ports that install files under
PYTHON_SITELIBDIR must use the
pyXY- package name prefix, so their package
name embeds the version of Python they are installed
into.PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}
Most Useful Variables for Ports That Use PythonUSES=pythonThe port needs Python. The minimal required
version can be specified with values such as
2.7+. Version ranges can also be
specified by separating two version numbers with a dash:
USES=python:3.2-3.3USE_PYTHON=distutilsUse Python distutils for configuring, compiling,
and installing. This is required when the port comes
with setup.py. This overrides
the do-build and
do-install targets and may
also override do-configure
if GNU_CONFIGURE is not
defined. Additionally, it implies
USE_PYTHON=flavors.USE_PYTHON=autoplistCreate the packaging list automatically. This also
requires USE_PYTHON=distutils to be
set.USE_PYTHON=concurrentThe port will use an unique prefix, typically
PYTHON_PKGNAMEPREFIX for certain
directories, such as EXAMPLESDIR and
DOCSDIR and also will append a
suffix, the python version from
PYTHON_VER, to binaries and scripts
to be installed. This allows ports to be installed for
different Python versions at the same time, which
otherwise would install conflicting files.USE_PYTHON=flavorsThe port does not use distutils but still supports
multiple Python versions. FLAVORS
will be set to the supported Python versions. See for more
information.USE_PYTHON=optsuffixIf the current Python version is not the default
version, the port will gain
PKGNAMESUFFIX=${PYTHON_PKGNAMESUFFIX}.
Only useful with flavors.PYTHON_PKGNAMEPREFIXUsed as a PKGNAMEPREFIX to
distinguish packages for different Python versions.
Example: py27-PYTHON_SITELIBDIRLocation of the site-packages tree, that contains
installation path of Python (usually
LOCALBASE).
PYTHON_SITELIBDIR can be
very useful when installing Python modules.PYTHONPREFIX_SITELIBDIRThe PREFIX-clean variant of PYTHON_SITELIBDIR.
Always use %%PYTHON_SITELIBDIR%% in
pkg-plist when possible. The
default value of
%%PYTHON_SITELIBDIR%% is
lib/python%%PYTHON_VERSION%%/site-packagesPYTHON_CMDPython interpreter command line, including
version number.
Python Module Dependency HelpersPYNUMERICDependency line for numeric extension.PYNUMPYDependency line for the new numeric extension,
numpy. (PYNUMERIC is deprecated by upstream
vendor).PYXMLDependency line for XML extension (not needed for
Python 2.0 and higher as it is also in base
distribution).PY_ENUM34Conditional dependency on
devel/py-enum34 depending on the
Python version.PY_ENUM_COMPATConditional dependency on
devel/py-enum-compat depending on the
Python version.PY_PATHLIBConditional dependency on
devel/py-pathlib depending on the
Python version.PY_IPADDRESSConditional dependency on
net/py-ipaddress depending on the
Python version.PY_FUTURESConditional dependency on
devel/py-futures depending on the
Python version.
A complete list of available variables can be found in
/usr/ports/Mk/Uses/python.mk.All dependencies to Python
ports using Python
flavors (either with
USE_PYTHON=distutils or
USE_PYTHON=flavors) must have the Python
flavor appended to their origin using
@${PY_FLAVOR}. See .Makefile for a Simple Python
ModulePORTNAME= sample
DISTVERSION= 1.2.3
CATEGORIES= devel
MAINTAINER= john@doe.tld
COMMENT= Python sample module
RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR}
USES= python
USE_PYTHON= autoplist distutils
.include <bsd.port.mk>Some Python applications claim to have
DESTDIR support (which would be required
for staging) but it is broken (Mailman up to 2.1.16, for
instance). This can be worked around by recompiling the
scripts. This can be done, for example, in the
post-build target. Assuming the
Python scripts are supposed to reside in
PYTHONPREFIX_SITELIBDIR after installation,
this solution can be applied:(cd ${STAGEDIR}${PREFIX} \
&& ${PYTHON_CMD} ${PYTHON_LIBDIR}/compileall.py \
-d ${PREFIX} -f ${PYTHONPREFIX_SITELIBDIR:S;${PREFIX}/;;})This recompiles the sources with a path relative to the
stage directory, and prepends the value of
PREFIX to the file name recorded in the
byte-compiled output file by -d.
-f is required to force recompilation, and
the :S;${PREFIX}/;; strips prefixes from
the value of PYTHONPREFIX_SITELIBDIR
to make it relative to
PREFIX.Using Tcl/TkThe Ports Collection supports parallel installation of
multiple Tcl/Tk versions. Ports
should try to support at least the default
Tcl/Tk version and higher with
USES=tcl. It is possible to specify the
desired version of tcl by appending
:xx, for example,
USES=tcl:85.
The Most Useful Read-Only Variables for Ports That Use
Tcl/TkTCL_VER chosen major.minor version of
TclTCLSH full path of the Tcl
interpreterTCL_LIBDIR path of the Tcl
librariesTCL_INCLUDEDIR path of the Tcl C
header filesTK_VER chosen major.minor version of
TkWISH full path of the Tk
interpreterTK_LIBDIR path of the Tk
librariesTK_INCLUDEDIR path of the Tk C header
files
See the USES=tcl and
USES=tk of
for a full description of those
variables. A complete list of those variables is available in
/usr/ports/Mk/Uses/tcl.mk.Using Ruby
Useful Variables for Ports That Use RubyVariableDescriptionUSE_RUBYAdds build and run dependencies on Ruby.USE_RUBY_EXTCONFThe port uses extconf.rb to
configure.USE_RUBY_SETUPThe port uses setup.rb to
configure.RUBY_SETUPOverride the name of the setup script from
setup.rb. Another common value is
install.rb.
This table shows the selected variables available
to port authors via the ports infrastructure. These variables
are used to install files into their proper locations.
Use them in pkg-plist as much as
possible. Do not redefine these variables in the port.
Selected Read-Only Variables for Ports That Use
RubyVariableDescriptionExample valueRUBY_PKGNAMEPREFIXUsed as a PKGNAMEPREFIX to
distinguish packages for different Ruby
versions.ruby19-RUBY_VERSIONFull version of Ruby in the form of
x.y.z[.p].1.9.3.484RUBY_SITELIBDIRArchitecture independent libraries installation
path./usr/local/lib/ruby/site_ruby/1.9RUBY_SITEARCHLIBDIRArchitecture dependent libraries installation
path./usr/local/lib/ruby/site_ruby/1.9/amd64-freebsd10RUBY_MODDOCDIRModule documentation installation path./usr/local/share/doc/ruby19/patsyRUBY_MODEXAMPLESDIRModule examples installation path./usr/local/share/examples/ruby19/patsy
A complete list of available variables can be found in
/usr/ports/Mk/bsd.ruby.mk.Using SDLUSE_SDL is used to
autoconfigure the dependencies for ports which use an SDL
based library like devel/sdl12
and graphics/sdl_image.These SDL libraries for version 1.2 are recognized:sdl: devel/sdl12console: devel/sdl_consolegfx: graphics/sdl_gfximage: graphics/sdl_imagemixer: audio/sdl_mixermm: devel/sdlmmnet: net/sdl_netpango: x11-toolkits/sdl_pangosound: audio/sdl_soundttf: graphics/sdl_ttfThese SDL libraries for version 2.0 are recognized:sdl: devel/sdl20gfx: graphics/sdl2_gfximage: graphics/sdl2_imagemixer: audio/sdl2_mixernet: net/sdl2_netttf: graphics/sdl2_ttfTherefore, if a port has a dependency on
net/sdl_net and
audio/sdl_mixer,
the syntax will be:USE_SDL= net mixerThe dependency
devel/sdl12, which is
required by net/sdl_net
and audio/sdl_mixer, is
automatically added as well.Using USE_SDL with entries for
SDL 1.2, it will automatically:Add a dependency on
sdl12-config to
BUILD_DEPENDSAdd the variable SDL_CONFIG to
CONFIGURE_ENVAdd the dependencies of the selected libraries to
LIB_DEPENDSUsing USE_SDL with entries for
SDL 2.0, it will automatically:Add a dependency on
sdl2-config to
BUILD_DEPENDSAdd the variable SDL2_CONFIG to
CONFIGURE_ENVAdd the dependencies of the selected libraries to
LIB_DEPENDSUsing wxWidgetsThis section describes the status of the
wxWidgets libraries in the ports
tree and its integration with the ports system.IntroductionThere are many versions of the
wxWidgets libraries which
conflict between them (install files under the same name).
In the ports tree this problem has been solved by installing
each version under a different name using version number
suffixes.The obvious disadvantage of this is that each
application has to be modified to find the expected version.
Fortunately, most of the applications call the
wx-config script to determine the
necessary compiler and linker flags. The script is named
differently for every available version. Majority of
applications respect an environment variable, or accept a
configure argument, to specify which
wx-config script to call. Otherwise they
have to be patched.Version SelectionTo make the port use a specific version of
wxWidgets there are two variables
available for defining (if only one is defined the other
will be set to a default value):
Variables to Select
wxWidgets VersionsVariableDescriptionDefault valueUSE_WXList of versions the port can useAll available versionsUSE_WX_NOTList of versions the port cannot useNone
The available
wxWidgets versions and the
corresponding ports in the tree are:
Available wxWidgets
VersionsVersionPort2.8x11-toolkits/wxgtk283.0x11-toolkits/wxgtk30
The variables in can
be set to one or more of these combinations
separated by spaces:
wxWidgets Version
SpecificationsDescriptionExampleSingle version2.8Ascending range2.8+Descending range3.0-Full range (must be ascending)2.8-3.0
There are also some variables to select the preferred
versions from the available ones. They can be set to a list
of versions, the first ones will have higher
priority.
Variables to Select Preferred
wxWidgets VersionsNameDesigned forWANT_WX_VERthe portWITH_WX_VERthe user
Component SelectionThere are other applications that, while not being
wxWidgets libraries, are related
to them. These applications can be specified in
WX_COMPS. These
components are available:
Available wxWidgets
ComponentsNameDescriptionVersion restrictionwxmain librarynonecontribcontributed librariesnonepythonwxPython
(Python bindings)2.8-3.0
The dependency type can be selected for each component
by adding a suffix separated by a semicolon. If not present
then a default type will be used (see
). These types
are available:
Available wxWidgets
Dependency TypesNameDescriptionbuildComponent is required for building, equivalent
to BUILD_DEPENDSrunComponent is required for running, equivalent
to RUN_DEPENDSlibComponent is required for building and running,
equivalent to LIB_DEPENDS
The default values for the components are detailed in
this table:
Selecting wxWidgets
ComponentsThis fragment corresponds to a port which
uses wxWidgets version
2.4 and its contributed
libraries.USE_WX= 2.8
WX_COMPS= wx contribDetecting Installed VersionsTo detect an installed version, define
WANT_WX. If it is not set to a
specific version then the components will have a version
suffix. HAVE_WX will be
filled after detection.Detecting Installed
wxWidgets Versions and
ComponentsThis fragment can be used in a port that uses
wxWidgets if it is installed,
or an option is selected.WANT_WX= yes
.include <bsd.port.pre.mk>
.if defined(WITH_WX) || !empty(PORT_OPTIONS:MWX) || !empty(HAVE_WX:Mwx-2.8)
USE_WX= 2.8
CONFIGURE_ARGS+= --enable-wx
.endifThis fragment can be used in a port that
enables wxPython support if it
is installed or if an option is selected, in addition to
wxWidgets, both version
2.8.USE_WX= 2.8
WX_COMPS= wx
WANT_WX= 2.8
.include <bsd.port.pre.mk>
.if defined(WITH_WXPYTHON) || !empty(PORT_OPTIONS:MWXPYTHON) || !empty(HAVE_WX:Mpython)
WX_COMPS+= python
CONFIGURE_ARGS+= --enable-wxpython
.endifDefined VariablesThese variables are available in the port (after
defining one from
).
Variables Defined for Ports That Use
wxWidgetsNameDescriptionWX_CONFIGThe path to the
wxWidgetswx-config script (with different
name)WXRC_CMDThe path to the
wxWidgetswxrc program (with different
name)WX_VERSIONThe wxWidgets
version that is going to be used (for example,
2.6)
Processing in
bsd.port.pre.mkDefine WX_PREMK to be able to use the
variables right after including
bsd.port.pre.mk.When defining WX_PREMK, then the
version, dependencies, components and defined variables
will not change if modifying the
wxWidgets port variables
after including
bsd.port.pre.mk.Using wxWidgets Variables
in CommandsThis fragment illustrates the use of
WX_PREMK by running the
wx-config script to obtain the full
version string, assign it to a variable and pass it to the
program.USE_WX= 2.8
WX_PREMK= yes
.include <bsd.port.pre.mk>
.if exists(${WX_CONFIG})
VER_STR!= ${WX_CONFIG} --release
PLIST_SUB+= VERSION="${VER_STR}"
.endifThe wxWidgets variables can
be safely used in commands when they are inside targets
without the need of WX_PREMK.Additional configure
ArgumentsSome GNU configure scripts cannot
find wxWidgets with just the
WX_CONFIG environment variable set,
requiring additional arguments.
WX_CONF_ARGS can be used for
provide them.
Legal Values for
WX_CONF_ARGSPossible valueResulting argumentabsolute--with-wx-config=${WX_CONFIG}relative--with-wx=${LOCALBASE}
--with-wx-config=${WX_CONFIG:T}
Using LuaThis section describes the status of the
Lua libraries in the ports tree and
its integration with the ports system.IntroductionThere are many versions of the
Lua libraries and corresponding
interpreters, which conflict between them (install files
under the same name). In the ports tree this problem has
been solved by installing each version under a different
name using version number suffixes.The obvious disadvantage of this is that each
application has to be modified to find the expected version.
But it can be solved by adding some additional flags to the
compiler and linker.Version SelectionA port using Lua only needs to
have this line:USES= luaIf a specific version of Lua is needed, instructions on
how to select it are given in the USES=lua part
of .Defined VariablesThese variables are available in the port.
Variables Defined for Ports That Use
LuaNameDescriptionLUA_VERThe Lua version that
is going to be used (for example,
5.1)LUA_VER_STRThe Lua version
without the dots (for example,
51)LUA_PREFIXThe prefix where Lua
(and components) is installedLUA_SUBDIRThe directory under
${PREFIX}/bin,
${PREFIX}/share and
${PREFIX}/lib where
Lua is installedLUA_INCDIRThe directory where
Lua and
tolua header files are
installedLUA_LIBDIRThe directory where
Lua and
tolua libraries are
installedLUA_MODLIBDIRThe directory where
Lua module libraries
(.so) are installedLUA_MODSHAREDIRThe directory where
Lua modules
(.lua) are installedLUA_PKGNAMEPREFIXThe package name prefix used by
Lua modulesLUA_CMDThe path to the Lua
interpreterLUAC_CMDThe path to the Lua
compiler
Using iconvAfter 2013-10-08 (254273),
&os; 10-CURRENT and newer versions have a native
iconv in the operating system. On earlier
versions, converters/libiconv
was used as a dependency.For software that needs iconv, define
USES=iconv. &os; versions before
10-CURRENT on 2013-08-13 (254273) do
not have a native iconv. On these earlier
versions, a dependency on
converters/libiconv will be
added automatically.When a port defines USES=iconv, these
variables will be available:Variable namePurposeValue before &os; 10-CURRENT
254273 (2013-08-13)Value after &os; 10-CURRENT
254273 (2013-08-13)ICONV_CMDDirectory where the iconv
binary resides${LOCALBASE}/bin/iconv/usr/bin/iconvICONV_LIBld argument to link to
libiconv (if needed)-liconv(empty)ICONV_PREFIXDirectory where the iconv
implementation resides (useful for configure
scripts)${LOCALBASE}/usrICONV_CONFIGURE_ARGPreconstructed configure argument for
configure scripts--with-libiconv-prefix=${LOCALBASE}(empty)ICONV_CONFIGURE_BASEPreconstructed configure argument for
configure scripts--with-libiconv=${LOCALBASE}(empty)These two examples automatically populate the variables
with the correct value for systems using
converters/libiconv or the
native iconv respectively:Simple iconv UsageUSES= iconv
LDFLAGS+= -L${LOCALBASE}/lib ${ICONV_LIB}iconv Usage with
configureUSES= iconv
CONFIGURE_ARGS+=${ICONV_CONFIGURE_ARG}As shown above, ICONV_LIB is empty when
a native iconv is present. This can be
used to detect the native iconv and respond
appropriately.Sometimes a program has an ld argument
or search path hardcoded in a Makefile or
configure script. This approach can be used to solve that
problem:Fixing Hardcoded -liconvUSES= iconv
post-patch:
@${REINPLACE_CMD} -e 's/-liconv/${ICONV_LIB}/' ${WRKSRC}/MakefileIn some cases it is necessary to set alternate values or
perform operations depending on whether there is a native
iconv.
bsd.port.pre.mk must be included before
testing the value of ICONV_LIB:Checking for Native iconv
AvailabilityUSES= iconv
.include <bsd.port.pre.mk>
post-patch:
.if empty(ICONV_LIB)
# native iconv detected
@${REINPLACE_CMD} -e 's|iconv||' ${WRKSRC}/Config.sh
.endif
.include <bsd.port.post.mk>Using XfcePorts that need Xfce libraries or
applications set USES=xfce.Specific Xfce library and
application dependencies are set with values assigned to
USE_XFCE. They are defined in
/usr/ports/Mk/Uses/xfce.mk. The possible
values are:Values of USE_XFCEgarconsysutils/garconlibexox11/libexolibguix11-toolkits/libxfce4guilibmenux11/libxfce4menulibutilx11/libxfce4utilpanelx11-wm/xfce4-panelthunarx11-fm/thunarxfconfx11/xfce4-confUSES=xfce ExampleUSES= xfce
USE_XFCE= libmenu
-
- Using Xfce's Own GTK3 Widgets
+
+ Using Xfce's Own GTK2 WidgetsIn this example, the ported application uses the
- GTK3-specific widgets GTK2-specific widgets x11/libxfce4menu and x11/xfce4-conf.
- USES= xfce:gtk3
+ USES= xfce:gtk2
USE_XFCE= libmenu xfconfXfce components included this
way will automatically include any dependencies they need. It
is no longer necessary to specify the entire list. If the
port only needs x11-wm/xfce4-panel, use:USES= xfce
USE_XFCE= panelThere is no need to list the components x11-wm/xfce4-panel needs itself like
this:USES= xfce
USE_XFCE= libexo libmenu libutil panelHowever, Xfce components and
non-Xfce dependencies of the port
must be included explicitly. Do not count on an
Xfce component to provide a
sub-dependency other than itself for the main port.Using DatabasesUse one of the USES macros from
to add a dependency
on a database.
Using Berkeley DB 6USES= bdb:6See for more
information.Using MySQLWhen a port needs the MySQL
client library addUSES= mysqlSee for more
information.Using PostgreSQLWhen a port needs the
PostgreSQL server version 9.6
or later addUSES= pgsql:9.6+
WANT_PGSQL= serverSee for more
information.Using SQLite 3USES= sqlite:3See for more
information.Starting and Stopping Services (rc
Scripts)rc.d scripts are used to start
services on system startup, and to give administrators a
standard way of stopping, starting and restarting the service.
Ports integrate into the system rc.d
framework. Details on its usage can be found in the
rc.d Handbook chapter. Detailed explanation of
the available commands is provided in &man.rc.8; and
&man.rc.subr.8;. Finally, there is
an
article on practical aspects of
rc.d scripting.With a mythical port called
doorman, which needs to start a
doormand daemon. Add the following
to the Makefile:USE_RC_SUBR= doormandMultiple scripts may be listed and will be installed.
Scripts must be placed in the files
subdirectory and a .in suffix must be added
to their filename. Standard SUB_LIST
expansions will be ran against this file. Use of the
%%PREFIX%% and
%%LOCALBASE%% expansions is strongly
encouraged as well. More on SUB_LIST in
the relevant
section.As of &os; 6.1-RELEASE, local
rc.d scripts (including those installed
by ports) are included in the overall &man.rcorder.8; of the
base system.An example simple rc.d script to start
the doormand daemon:#!/bin/sh
# $FreeBSD$
#
# PROVIDE: doormand
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# Add these lines to /etc/rc.conf.local or /etc/rc.conf
# to enable this service:
#
# doormand_enable (bool): Set to NO by default.
# Set it to YES to enable doormand.
# doormand_config (path): Set to %%PREFIX%%/etc/doormand/doormand.cf
# by default.
. /etc/rc.subr
name=doormand
rcvar=doormand_enable
load_rc_config $name
: ${doormand_enable:="NO"}
: ${doormand_config="%%PREFIX%%/etc/doormand/doormand.cf"}
command=%%PREFIX%%/sbin/${name}
pidfile=/var/run/${name}.pid
command_args="-p $pidfile -f $doormand_config"
run_rc_command "$1"Unless there is a very good reason to start the service
earlier, or it runs as a particular user (other than root), all
ports scripts must use:REQUIRE: LOGINIf the startup script launches a daemon that must be
shutdown, the following will trigger a stop of the service on
system shutdown:KEYWORD: shutdownIf the script is not starting a persistent service this is
not necessary.For optional configuration elements the "="
style of default variable assignment is preferable to the
":=" style here, since the former sets a default
value only if the variable is unset, and the latter sets one
if the variable is unset or null. A user
might very well include something like:doormand_flags=""in their rc.conf.local, and a
variable substitution using ":=" would
inappropriately override the user's intention. The
_enable variable is not optional,
and must use the ":" for the default.Ports must not start and stop
their services when installing and deinstalling. Do not abuse
the plist keywords described in by running commands
that modify the currently running system, including starting
or stopping services.Pre-Commit ChecklistBefore contributing a port with an
rc.d script, and more importantly,
before committing one, please consult this
checklist to be sure that it is ready.The devel/rclint
port can check for most of these, but it is not a
substitute for proper review.If this is a new file, does it have a
.sh extension? If so, that must be
changed to just
file.in
since rc.d files may not end with
that extension.Does the file have a
$FreeBSD$ tag?Do the name of the file (minus
.in), the
PROVIDE line, and
$name
all match? The file name matching
PROVIDE makes debugging easier,
especially for &man.rcorder.8; issues. Matching the
file name and
$name
makes it easier to figure out which variables are
relevant in rc.conf[.local]. It is
also a policy
for all new scripts, including those in the base
system.Is the REQUIRE line set to
LOGIN? This is mandatory for scripts
that run as a non-root user. If it runs as root, is
there a good reason for it to run prior to
LOGIN? If not, it must run after
so that local scrips can be loosely grouped to a point in
&man.rcorder.8; after most everything in the base is
already running.Does the script start a persistent service? If so,
it must have KEYWORD:
shutdown.Make sure there is no
KEYWORD: &os; present. This has
not been necessary nor desirable for years. It is also
an indication that the new script was copy/pasted from
an old script, so extra caution must be given to the
review.If the script uses an interpreted language like
perl, python, or
ruby, make certain that
command_interpreter is set
appropriately, for example, for
Perl, by adding
PERL=${PERL} to
SUB_LIST and using
%%PERL%%. Otherwise,&prompt.root; service name stopwill probably not work properly. See
&man.service.8; for more information.Have all occurrences of
/usr/local been replaced with
%%PREFIX%%?Do the default variable assignments come after
load_rc_config?Are there default assignments to empty strings?
They should be removed, but double-check that the option
is documented in the comments at the top of the
file.Are things that are set in variables actually used
in the script?Are options listed in the default
name_flags
things that are actually mandatory? If so, they must
be in command_args.
is a red flag (pardon the
pun) here, since it is usually the option to
“daemonize” the process, and therefore is
actually mandatory.name_flags
must never be included in
command_args (and vice versa,
although that error is less common).Does the script execute any code unconditionally?
This is frowned on. Usually these things must be
dealt with through a
start_precmd.All boolean tests must use the
checkyesno function. No
hand-rolled tests for [Yy][Ee][Ss],
etc.If there is a loop (for example, waiting for
something to start) does it have a counter to terminate
the loop? We do not want the boot to be stuck forever
if there is an error.Does the script create files or directories that
need specific permissions, for example, a
pid that needs to be owned by
the user that runs the process? Rather than the
traditional &man.touch.1;/&man.chown.8;/&man.chmod.1;
routine, consider using &man.install.1; with the proper
command line arguments to do the whole procedure with
one step.Adding Users and GroupsSome ports require a particular user account to be present,
usually for daemons that run as that user. For these ports,
choose a unique UID from 50 to 999 and
register it in ports/UIDs (for users) and
ports/GIDs (for groups). The unique
identification should be the same for users and groups.Please include a patch against these two files when
requiring a new user or group to be created for the
port.Then use USERS and
GROUPS in
Makefile, and the user will be
automatically created when installing the port.USERS= pulse
GROUPS= pulse pulse-access pulse-rtThe current list of reserved UIDs and GIDs can be found
in ports/UIDs and
ports/GIDs.Ports That Rely on Kernel SourcesSome ports (such as kernel loadable modules) need the
kernel source files so that the port can compile. Here is the
correct way to determine if the user has them
installed:USES= kmodApart from this check, the kmod feature
takes care of most items that these ports need to take into
account.Go LibrariesPorts must not package or install Go libs or source code.
Go ports must fetch the required deps at the normal fetch time
and should only install the programs and things users need, not
the things Go developers would need.Ports should (in order of preference):Use vendored dependencies included with the package
source.Fetch the versions of deps specified by upstream (in the
case of go.mod, vendor.json or similar).As a last resort (deps are not included nor versions
specified exactly) fetch versions of dependencies available
at the time of upstream development/release.Shell Completion FilesMany modern shells (including bash, tcsh, and zsh) support
parameter and/or option tab-completion. This support usually
comes from completion files, which contain the definitions for
how tab completion will work for a certain command. Ports
sometimes ship with their own completion files, or porters may
have created them themselves.When available, completion files should always be
installed. It is not necessary to make an option for it.
If an option is used, though, always enable it in
OPTIONS_DEFAULT.
Do not register any dependencies on the shells
themselves.
Index: head/en_US.ISO8859-1/books/porters-handbook/uses/chapter.xml
===================================================================
--- head/en_US.ISO8859-1/books/porters-handbook/uses/chapter.xml (revision 53466)
+++ head/en_US.ISO8859-1/books/porters-handbook/uses/chapter.xml (revision 53467)
@@ -1,3799 +1,3799 @@
Using USES MacrosAn Introduction to USESUSES macros make it easy to declare
requirements and settings for a port. They can add
dependencies, change building behavior, add metadata to
packages, and so on, all by selecting simple, preset
values.Each section in this chapter describes a possible value for
USES, along with its possible arguments.
Arguments are appeneded to the value after a colon
(:). Multiple arguments are separated by
commas (,).Using Multiple ValuesUSES= bison perlAdding an ArgumentUSES= tar:xzAdding Multiple ArgumentsUSES= drupal:7,themeMixing it All TogetherUSES= pgsql:9.3+ cpe python:2.7,build7zPossible arguments: (none), p7zip,
partialExtract using &man.7z.1; instead of &man.bsdtar.1; and sets
EXTRACT_SUFX=.7z. The
p7zip option forces a dependency on the
7z from archivers/p7zip if the one from the base
system is not able to extract the files.
EXTRACT_SUFX is not changed if the
partial option is used, this can be used if
the main distribution file does not have a
.7z extension.adaPossible arguments: (none),
5,
6Depends on an Ada-capable
compiler, and sets CC accordingly. Defaults
to use gcc 5 from ports. Use the
:X version option
to force building with a different version.autoreconfPossible arguments: (none), buildRuns autoreconf. It encapsulates the
aclocal, autoconf,
autoheader, automake,
autopoint, and libtoolize
commands. Each command applies to
${AUTORECONF_WRKSRC}/configure.ac or its
old name,
${AUTORECONF_WRKSRC}/configure.in. If
configure.ac defines subdirectories with
their own configure.ac using
AC_CONFIG_SUBDIRS,
autoreconf will recursively update those as
well. The :build argument only adds build
time dependencies on those tools but does not run
autoreconf. A port can set
AUTORECONF_WRKSRC if
WRKSRC does not contain the path to
configure.ac.blaslapackPossible arguments: (none), atlas,
netlib (default),
gotoblas, openblasAdds dependencies on Blas / Lapack libraries.bdbPossible arguments: (none), 48,
5 (default), 6Add dependency on the Berkeley DB
library. Default to databases/db5. It can also depend on
databases/db48 when using the
:48 argument or databases/db6 with
:6. It is possible to declare a range of
acceptable values, :48+ finds the highest
installed version, and falls back to 4.8 if nothing else is
installed. INVALID_BDB_VER can be used to
specify versions which do not work with this port. The
framework exposes the following variables to the port:BDB_LIB_NAMEThe name of the Berkeley DB
library. For example, when using databases/db5, it contains
db-5.3.BDB_LIB_CXX_NAMEThe name of the Berkeley DBC++ library. For example, when
using databases/db5, it
contains db_cxx-5.3.BDB_INCLUDE_DIRThe location of the Berkeley
DB include directory. For example, when
using databases/db5, it
will contain
${LOCALBASE}/include/db5.BDB_LIB_DIRThe location of the Berkeley
DB library directory. For example, when
using databases/db5, it
contains ${LOCALBASE}/lib.BDB_VERThe detected Berkeley DB
version. For example, if using
USES=bdb:48+ and Berkeley
DB 5 is installed, it contains
5.databases/db48 is
deprecated and unsupported. It must not be used by any
port.bisonPossible arguments: (none), build,
run, bothUses devel/bison By default,
with no arguments or with the build argument,
it implies bison is a build-time dependency,
run implies a run-time dependency, and
both implies both run-time and build-time
dependencies.cargoPossible arguments: (none)Uses Cargo for configuring, building, and testing.
It can be used to port Rust applications that use the Cargo
build system. For more information see .charsetfixPossible arguments: (none)Prevents the port from installing
charset.alias. This must be installed only
by converters/libiconv.
CHARSETFIX_MAKEFILEIN can be set to a path
relative to WRKSRC if
charset.alias is not installed by
${WRKSRC}/Makefile.in.cmakePossible arguments: (none), insource,
noninja, runUses CMake for configuring and
building.By default an out-of-source build is performed, leaving the
sources in WRKSRC free from build artifacts.
With the insource argument, an in-source
build will be performed instead. Setting it should be the
exception when a regular out-of-source build does not
work.By default Ninja is used for
the build. In some cases this does not work correctly. With
the noninja argument, the build will
fallback to using regular make for builds.
It should only be used if a
Ninja-based build does not
work.With the run argument, a run dependency
is registered in addition to a build dependency.For more information see .compilerPossible arguments: (none), env
(default, implicit), c++17-lang,
c++14-lang,
c++11-lang, gcc-c++11-lib,
c++11-lib, c++0x,
c11, openmp,
nestedfct, featuresDetermines which compiler to use based on any given wishes.
Use c++17-lang if the port needs a
C++17-capable compiler,
c++14-lang if the port needs a
C++14-capable compiler, c++11-lang
if the port needs a C++11-capable compiler,
gcc-c++11-lib if the
port needs the g++ compiler with a C++11
library, or c++11-lib if the port needs
a C++11-ready standard library. If the port needs a compiler
understanding C++0X, C11, OpenMP, or nested functions,
the corresponding parameters should be used.Use
features to request a list of features
supported by the default compiler. After including
bsd.port.pre.mk the port can inspect the
results using these variables:COMPILER_TYPE: the default compiler
on the system, either gcc or clangALT_COMPILER_TYPE: the alternative
compiler on the system, either gcc or clang. Only set if
two compilers are present in the base system.COMPILER_VERSION: the first two
digits of the version of the default compiler.ALT_COMPILER_VERSION: the first two
digits of the version of the alternative compiler, if
present.CHOSEN_COMPILER_TYPE: the chosen
compiler, either gcc or clangCOMPILER_FEATURES: the features
supported by the default compiler. It currently lists the
C++ library.cpePossible arguments: (none)Include Common Platform Enumeration
(CPE) information in package manifest as a
CPE 2.3 formatted string. See the CPE
specification for details. To add
CPE information to a port, follow these
steps:Search for the official CPE entry for the software
product either by using the NVD's CPE
search engine or in the official
CPE dictionary (warning, very
large XML file). Do not ever
make up CPE data.Add cpe to USES
and compare the result of make -V CPE_STR
to the CPE dictionary entry. Continue one
step at a time until make -V CPE_STR is
correct.If the product name (second field, defaults to
PORTNAME) is incorrect, define
CPE_PRODUCT.If the vendor name (first field, defaults to
CPE_PRODUCT) is incorrect, define
CPE_VENDOR.If the version field (third field, defaults to
PORTVERSION) is incorrect, define
CPE_VERSION.If the update field (fourth field, defaults to empty) is
incorrect, define CPE_UPDATE.If it is still not correct, check
Mk/Uses/cpe.mk for additional details,
or contact the &a.ports-secteam;.Derive as much as possible of the CPE
name from existing variables such as
PORTNAME and
PORTVERSION. Use variable modifiers to
extract the relevant portions from these variables rather
than hardcoding the name.Always run make -V
CPE_STR and check the output before committing
anything that changes PORTNAME or
PORTVERSION or any other variable which
is used to derive CPE_STR.cranPossible arguments: (none),
auto-plist,
compilesUses the Comprehensive R Archive Network. Specify
auto-plist to automatically generate
pkg-plist. Specify
compiles if the port has code that need to be
compiled.desktop-file-utilsPossible arguments: (none)Uses update-desktop-database from
devel/desktop-file-utils. An
extra post-install step will be run without interfering with any
post-install steps already in the port
Makefile. A line with @desktop-file-utils
will be added to the plist.desthackPossible arguments: (none)Changes the behavior of GNU configure to properly support
DESTDIR in case the original software does
not.displayPossible arguments: (none),
ARGSSet up a virtual display environment. If the environment
variable DISPLAY is not set, then
Xvfb is added as a build dependency,
and CONFIGURE_ENV is extended with the port
number of the currently running instance of
Xvfb. The
ARGS
parameter defaults to install and controls
the phase around which to start and stop the virtual
display.dos2unixPossible arguments: (none)The port has files with line endings in
DOS format which need to be converted.
Several variables can be set to control which files will be
converted. The default is to convert all
files, including binaries. See for
examples.DOS2UNIX_REGEX: match file names
based on a regular expression.DOS2UNIX_FILES: match literal file
names.DOS2UNIX_GLOB: match file names based
on a glob pattern.DOS2UNIX_WRKSRC: the directory from
which to start the conversions. Defaults to
${WRKSRC}.drupalPossible arguments:
7, module,
themeAutomate installation of a port that is a
Drupal theme or module. Use with the
version of Drupal that the port is expecting. For example,
USES=drupal:7,module says that this port
creates a Drupal 6 module. A Drupal 7 theme can be specified
with USES=drupal:7,theme.fakerootPossible arguments: (none)Changes some default behavior of build systems to allow
installing as a user. See for more
information on fakeroot.famPossible arguments: (none), fam,
gaminUses a File Alteration Monitor as a library dependency,
either devel/fam or devel/gamin. End users can set
WITH_FAM_SYSTEM to specify their preference.firebirdPossible arguments: (none), 25Add a dependency to the client library of the Firebird
database.fontsPossible arguments: (none), fc,
fcfontsdir (default),
fontsdir, noneAdds a runtime dependency on tools needed to register fonts.
Depending on the argument, add a @fc ${FONTSDIR}
line, @fcfontsdir
${FONTSDIR} line, @fontsdir
${FONTSDIR} line, or no line if the argument is
none, to the plist.
FONTSDIR defaults to
${PREFIX}/share/fonts/${FONTNAME} and
FONTNAME to ${PORTNAME}.
Add FONTSDIR to PLIST_SUB
and SUB_LISTfortranPossible arguments: gcc (default)Uses the GNU Fortran compiler.fusePossible arguments: 2 (default),
3The port will depend on the FUSE library and handle the
dependency on the kernel module depending on the version of
&os;.gemPossible arguments: (none),
noautoplistHandle building with RubyGems.
If noautoplist is used, the packing list is
not generated automatically.gettextPossible arguments: (none)Deprecated. Will include both gettext-runtime
and gettext-tools.gettext-runtimePossible arguments: (none), lib
(default), build,
runUses devel/gettext-runtime.
By default, with no arguments or with the lib
argument, implies a library dependency on
libintl.so. build and
run implies, respectively a build-time and a
run-time dependency on gettext.gettext-toolsPossible arguments: (none), build
(default), runUses devel/gettext-tools. By
default, with no argument, or with the build
argument, a build time dependency on msgfmt
is registered. With the run argument, a
run-time dependency is registered.ghostscriptPossible arguments: X,
build, run,
nox11A specific version X can be used.
Possible versions are 7,
8, 9, and
agpl (default). nox11
indicates
that the -nox11 version of the port is
required. build and run
add build- and run-time dependencies on
Ghostscript. The default is both
build- and run-time dependencies.glPossible arguments: (none)Provides an easy way to depend on
GL components. The components
should be listed in USE_GL. The available
components are:egladd a library dependency on libEGL.so
from graphics/mesa-libsgbmAdd a library dependency on libgbm.so
from graphics/mesa-libsglAdd a library dependency on libGL.so
from graphics/mesa-libsglesv2Add a library dependency on libGLESv2.so
from graphics/mesa-libsglewAdd a library dependency on libGLEW.so
from graphics/glewgluAdd a library dependency on libGLU.so
from graphics/libGLUglutAdd a library dependency on libglut.so
from graphics/freeglutglwAdd a library dependency on libGLw.so
from graphics/libGLwgmakePossible arguments: (none)Uses devel/gmake as a
build-time dependency and sets up the environment to use
gmake as the default make
for the build.gnomePossible arguments: (none)Provides an easy way to depend on
GNOME components. The components
should be listed in USE_GNOME. The available
components are:atkatkmmcairocairommdconfesoundevolutiondataserver3gconf2gconfmm26gdkpixbufgdkpixbuf2glib12glib20glibmmgnomecontrolcenter3gnomedesktop3gnomedocutilsgnomemenus3gnomemimedatagnomeprefixgnomesharp20gnomevfs2gsoundgtk-update-icon-cachegtk12gtk20gtk30gtkhtml3gtkhtml4gtkmm20gtkmm24gtkmm30gtksharp20gtksourceviewgtksourceview2gtksourceview3gtksourceviewmm3gvfsintlhackintltoolintrospectionlibartlgpl2libbonobolibbonobouilibgda5libgda5-uilibgdamm5libglade2libgnomelibgnomecanvaslibgnomekbdlibgnomeprintlibgnomeprintuilibgnomeuilibgsflibgtkhtmllibgtksourceviewmmlibidllibrsvg2libsigc++12libsigc++20libwncklibwnck3libxml++26libxml2libxsltmetacitynautilus3orbit2pangopangommpangox-compatpy3gobject3pygnome2pygobjectpygobject3pygtk2pygtksourceviewreferencehackvtevte3The default dependency is build- and run-time, it can be
changed with :build or
:run. For example:USES= gnome
USE_GNOME= gnomemenus3:build intlhackSee for more
information.goPorts should not be created for Go libs, see
for more information.Possible arguments: (none), modules,
no_targets, runSets default values and targets used to build
Go software. A build dependency
on the Go compiler port selected via GO_PORT
is added. By default the build is performed in GOPATH mode.
If Go software uses modules, the modules-aware mode can be
switched on with modules argument.
no_targets will setup build environment like
GO_ENV, GO_BUILDFLAGS but
skip creating post-extract,
do-build and
do-install targets.
run will also add a run dependency on
what is in GO_PORT.The build process is controlled by several variables:GO_PKGNAMEThe name of the Go package
when building in GOPATH mode. This is the directory that
will be created in ${GOPATH}/src. If
not set explicitly and GH_SUBDIR or
GL_SUBDIR is present,
GO_PKGNAME will be inferred from it.
It is not needed when building in modules-aware
mode.GO_TARGETThe packages to build. The default
value is ${GO_PKGNAME}.
GO_TARGET can also be a tuple in the
form package:path where path can be
either a simple filename or a full path starting with
${PREFIX}.CGO_CFLAGSAdditional CFLAGS values to be
passed to the C compiler by
go.CGO_LDFLAGSAdditional LDFLAGS values to be
passed to the C compiler by
go.GO_BUILDFLAGSAdditional build arguments to be passed to
go install.GO_PORTThe Go compiler port to use. By default this is
lang/go but can be set
to lang/go-devel in
make.conf for testing with future Go
versions.This variable must not be set by individual
ports!See for usage examples.gperfPossible arguments: (none)Add a buildtime dependency on devel/gperf if gperf
is not present in the base system.grantleePossible arguments: 5,
selfbuildHandle dependency on Grantlee.
Specify 5 to depend on the
Qt5 based version, devel/grantlee5.
selfbuild is used internally by devel/grantlee5 to get their versions
numbers.groffPossible arguments: build,
run, bothRegisters a dependency on textproc/groff if not present in the
base system.gssapiPossible arguments: (none), base
(default), heimdal, mit,
flags, bootstrapHandle dependencies needed by consumers of the
GSS-API. Only libraries that provide the
Kerberos mechanism are available. By
default, or set to base, the
GSS-API library from the base system is used.
Can also be set to heimdal to use security/heimdal, or
mit to use security/krb5.When the local Kerberos
installation is not in LOCALBASE, set
HEIMDAL_HOME (for heimdal)
or KRB5_HOME (for krb5) to
the location of the Kerberos
installation.These variables are exported for the ports to use:GSSAPIBASEDIRGSSAPICPPFLAGSGSSAPIINCDIRGSSAPILDFLAGSGSSAPILIBDIRGSSAPILIBSGSSAPI_CONFIGURE_ARGSThe flags option can be given alongside
base, heimdal, or
mit to automatically add
GSSAPICPPFLAGS,
GSSAPILDFLAGS, and
GSSAPILIBS to CFLAGS,
LDFLAGS, and LDADD,
respectively. For example, use
base,flags.The bootstrap option is a special prefix
only for use by security/krb5 and
security/heimdal. For example,
use bootstrap,mit.Typical UseOPTIONS_SINGLE= GSSAPI
OPTIONS_SINGLE_GSSAPI= GSSAPI_BASE GSSAPI_HEIMDAL GSSAPI_MIT GSSAPI_NONE
GSSAPI_BASE_USES= gssapi
GSSAPI_BASE_CONFIGURE_ON= --with-gssapi=${GSSAPIBASEDIR} ${GSSAPI_CONFIGURE_ARGS}
GSSAPI_HEIMDAL_USES= gssapi:heimdal
GSSAPI_HEIMDAL_CONFIGURE_ON= --with-gssapi=${GSSAPIBASEDIR} ${GSSAPI_CONFIGURE_ARGS}
GSSAPI_MIT_USES= gssapi:mit
GSSAPI_MIT_CONFIGURE_ON= --with-gssapi=${GSSAPIBASEDIR} ${GSSAPI_CONFIGURE_ARGS}
GSSAPI_NONE_CONFIGURE_ON= --without-gssapihordePossible arguments: (none)Add buildtime and runtime dependencies on devel/pear-channel-horde. Other
Horde dependencies can be added
with USE_HORDE_BUILD and
USE_HORDE_RUN. See for more information.iconvPossible arguments: (none), lib,
build,
patch, translit,
wchar_tUses iconv functions, either from the
port converters/libiconv as a
build-time and run-time dependency, or from the base system on
10-CURRENT after a native iconv was committed
in 254273. By default, with no arguments
or with the lib argument, implies
iconv with build-time and run-time
dependencies. build implies a build-time
dependency, and patch implies a patch-time
dependency. If the port uses the WCHAR_T or
//TRANSLIT iconv extensions, add the relevant
arguments so that the correct iconv is used. For more
information see .imakePossible arguments: (none), env,
notall, nomanAdd devel/imake as a
build-time dependency and run xmkmf -a during
the configure stage. If the
env argument is given, the
configure target is not set. If the
flag is a problem for the port, add the
notall argument. If xmkmf
does not generate a install.man
target, add the noman argument.kdePossible arguments: 5Add dependency on KDE components.
See for more information.kmodPossible arguments: (none), debugFills in the boilerplate for kernel module ports,
currently:Add kld to
CATEGORIES.Set SSP_UNSAFE.Set IGNORE if the kernel sources are
not found in SRC_BASE.Define KMODDIR to
/boot/modules by default, add it to
PLIST_SUB and
MAKE_ENV, and create it upon
installation. If KMODDIR is set to
/boot/kernel, it will be rewritten to
/boot/modules. This prevents breaking
packages when upgrading the kernel due to
/boot/kernel being renamed to
/boot/kernel.old in the process.Handle cross-referencing kernel modules upon
installation and deinstallation, using @kld.If the debug argument is given, the
port can install a debug version of the module into
KERN_DEBUGDIR/KMODDIR.
By default, KERN_DEBUGDIR is copied from
DEBUGDIR and set to
/usr/lib/debug. The framework will
take care of creating and removing any required
directories.lhaPossible arguments: (none)Set EXTRACT_SUFX to
.lzhlibarchivePossible arguments: (none)Registers a dependency on archivers/libarchive. Any ports
depending on libarchive must include
USES=libarchive.libeditPossible arguments: (none)Registers a dependency on devel/libedit. Any ports depending on
libedit must include
USES=libedit.libtoolPossible arguments: (none), keepla,
buildPatches libtool scripts. This must be
added to all ports that use libtool. The
keepla argument can be used to keep
.la files. Some ports do not ship with
their own copy of libtool and need a build time dependency on
devel/libtool, use the
:build argument to add such
dependency.linuxPossible arguments: c6,
c7Ports Linux compatibility
framework. Specify c6 to depend on
CentOS 6 packags. Specify
c7 to depend on
CentOS 7 packages. The available
packages are:allegroalsa-plugins-ossalsa-plugins-pulseaudioalsalibatkavahi-libsbasecairocups-libscurlcyrus-sasl2dbusglibdbuslibsdevtoolsdriexpatflacfontconfiggdkpixbuf2gnutlsgraphite2gtk2harfbuzzjasperjbigkitjpeglibasyncnslibaudiofilelibelflibgcryptlibgfortranlibgpg-errorlibmnglibogglibpciaccesslibsndfilelibsouplibssh2libtasn1libthailibtheoralibv4llibvorbislibxml2mikmodnaslibsncurses-basensprnssopenalopenal-softopenldapopenmotifopensslpangopixmanpngpulseaudio-libsqtqt-x11qtwebkitscimlibssdl12sdlimagesdlmixersqlite3tcl85tcp_wrappers-libstifftk85uclxorglibslocalbasePossible arguments: (none),
ldflagsEnsures that libraries from dependencies in
LOCALBASE are used instead of the ones from
the base system. Specify ldflags to add
-L${LOCALBASE}/lib to
LDFLAGS instead of LIBS.
Ports that depend on libraries that are also
present in the base system should use this. It is also used
internally by a few other USES.luaPossible arguments: (none),
XY+,
XY,
build, runAdds a dependency on Lua. By
default this is a library dependency, unless overridden by the
build or run option. The
default version is 5.2, unless set by the
XY parameter (for
example, 51 or
52+).lxqtPossible arguments: (none)Handle dependencies for the LXQt Desktop
Environment. Use USE_LXQT to
select the components needed for the port. See for more information.makeinfoPossible arguments: (none)Add a build-time dependency on makeinfo
if it is not present in the base system.makeselfPossible arguments: (none)Indicates that the distribution files are makeself archives
and sets the appropriate dependencies.matePossible arguments: (none)Provides an easy way to depend on
MATE components. The components
should be listed in USE_MATE. The available
components are:autogencajacommoncontrolcenterdesktopdialogsdocutilsiconthemeintlhackintltoollibmatekbdlibmateweathermarcomenusnotificationdaemonpanelplumapolkitsessionsettingsdaemonThe default dependency is build- and run-time, it can be
changed with :build or
:run. For example:USES= mate
USE_MATE= menus:build intlhackmesonPossible arguments: (none)Provide support for Meson based projects. For more
information see .metaportPossible arguments: (none)Sets the following variables to make it easier to create a
metaport: MASTER_SITES,
DISTFILES, EXTRACT_ONLY,
NO_BUILD, NO_INSTALL,
NO_MTREE, NO_ARCH.mysqlPossible arguments: (none),
version,
client (default), server,
embeddedProvide support for MySQL. If no
version is given, try to find the current installed version.
Fall back to the default version, MySQL-5.6. The possible
versions are 55, 55m,
55p, 56,
56p, 56w,
57, 57p,
80, 100m,
101m, and 102m. The
m and p suffixes are for
the MariaDB and
Percona variants of
MySQL. server and
embedded add a build- and run-time dependency
on the MySQL server. When using
server or embedded, add
client to also add a dependency on
libmysqlclient.so. A port can set
IGNORE_WITH_MYSQL if some versions are not
supported.The framework sets MYSQL_VER to the
detected MySQL version.monoPossible arguments: (none), nugetAdds a dependency on the Mono
(currently only C#) framework by setting the appropriate
dependencies.Specify nuget when the port uses nuget
packages. NUGET_DEPENDS needs to be set with
the names and versions of the nuget packages in the format
name=version.
An optional package origin can be added using
name=version:origin.The helper target, buildnuget,
will output the content of the NUGET_DEPENDS
based on the provided
packages.config.motifPossible arguments: (none)Uses x11-toolkits/open-motif
as a library dependency. End users can set
WANT_LESSTIF for the dependency to be on
x11-toolkits/lesstif instead of
x11-toolkits/open-motif.ncursesPossible arguments: (none), base,
portUses ncurses, and causes some
useful variables to be set.ninjaPossible arguments: (none)Uses ninja to build the
port.objcPossible arguments: (none)Add objective C dependencies (compiler, runtime library) if
the base system does not support it.openalPossible arguments: al,
soft (default), si,
alutUses OpenAL. The backend can be
specified, with the software implementation as the default. The
user can specify a preferred backend with
WANT_OPENAL. Valid values for this knob are
soft (default) and
si.pathfixPossible arguments: (none)Look for Makefile.in and
configure in
PATHFIX_WRKSRC (defaults to
WRKSRC)
and fix common paths to make sure they respect the &os;
hierarchy. For example, it fixes the installation directory
of pkgconfig's .pc files
to ${PREFIX}/libdata/pkgconfig. If
the port uses USES=autoreconf,
Makefile.am will be added to
PATHFIX_MAKEFILEIN automatically.If the port USES=cmake it
will look for CMakeLists.txt in
PATHFIX_WRKSRC. If needed, that default
filename can be changed with
PATHFIX_CMAKELISTSTXT.pearPossible arguments: envAdds a dependency on devel/pear. It will setup default
behavior for software using the PHP
Extension and Application Repository. Using the
env arguments only sets up the
PEAR environment variables. See
for more information.perl5Possible arguments: (none)Depends on Perl. The
configuration is done using USE_PERL5.USE_PERL5 can contain the phases in which
to use Perl, can be
extract, patch,
build, run, or
test.USE_PERL5 can also contain
configure,
modbuild, or modbuildtiny
when Makefile.PL,
Build.PL, or
Module::Build::Tiny's flavor of
Build.PL is required.USE_PERL5 defaults to build
run. When using configure,
modbuild, or modbuildtiny,
build and run are
implied.See for more
information.pgsqlPossible arguments: (none),
X.Y,
X.Y+,
X.Y-Provide support for PostgreSQL. Maintainer can set version
required. Minimum and maximum versions can be specified; for
example, 9.0-, 8.4+.Add PostgreSQL component dependency, using
WANT_PGSQL=component[:target]. for example,
WANT_PGSQL=server:configure pltcl plperl.
The available components are:clientcontribdocspgtclplperlplpythonpltclserverphpPossible arguments: (none), phpize,
ext, zend,
build, cli,
cgi, mod,
web, embed,
pecl, flavors,
noflavorsProvide support for PHP. Add a
runtime dependency on the default PHP version, lang/php56.phpizeUse to build a PHP
extension. Enables flavors.extUse to build, install and register a
PHP extension. Enables
flavors.zendUse to build, install and register a Zend
extension. Enables flavors.buildSet PHP also as a
build-time dependency.cliNeeds the CLI version of
PHP.cgiNeeds the CGI version of
PHP.modNeeds the Apache module for
PHP.webNeeds the Apache module or
the CGI version of
PHP.embedNeeds the embedded library version of
PHP.peclProvide defaults for fetching
PHP extensions from the PECL
repository. Enables flavors.flavorsEnable automatic PHP
flavors generation. Flavors will be generated
for all PHP versions, except the ones present in
IGNORE_WITH_PHP.noflavorsDisable automatic PHP
flavors generation. Must only be
used with extensions provided by
PHP itself.Variables are used to specify which
PHP modules are required, as well as
which version of PHP are
supported.USE_PHPThe list of required PHP
extensions at run-time. Add :build to
the extension name to add a build-time dependency.
Example: pcre xml:build gettextIGNORE_WITH_PHPThe port does not work with
PHP of the given version. For
possible values look at the content of
_ALL_PHP_VERSIONS in
Mk/Uses/php.mk.When building a PHP or
Zend extension with
:ext or :zend, these
variables can be set:PHP_MODNAMEThe name of the PHP or
Zend extension. Default value
is ${PORTNAME}.PHP_HEADER_DIRSA list of subdirectories from which to install header
files. The framework will always install the header files
that are present in the same directory as the
extension.PHP_MOD_PRIOThe priority at which to load the extension. It is a
number between 00 and
99.For extensions that do not depend on any extension,
the priority is automatically set to
20, for extensions that depend on
another extension, the priority is automatically set to
30. Some extensions may need to be
loaded before every other extension, for example www/php56-opcache. Some may need
to be loaded after an extension with a priority of
30. In that case, add
PHP_MOD_PRIO=XX
in the port's Makefile. For example:USES= php:ext
USE_PHP= wddx
PHP_MOD_PRIO= 40These variables are available to use in
PKGNAMEPREFIX or
PKGNAMESUFFIX:PHP_PKGNAMEPREFIXContains
phpXY- where
XY is the current flavor's PHP
version. Use with PHP extensions and modules.PHP_PKGNAMESUFFIXContains
-phpXY where
XY is the current flavor's PHP
version. Use with PHP applications.PECL_PKGNAMEPREFIXContains
phpXY-pecl-
where XY is the current
flavor's PHP version. Use with
PECL modules.With flavors, all PHP extensions, PECL extensions, PEAR
modules must have a different package
name, so they must all use one of these three variables in
their PKGNAMEPREFIX or
PKGNAMESUFFIX.pkgconfigPossible arguments: (none), build
(default), run,
bothUses devel/pkgconf. With no
arguments or with the build argument, it
implies pkg-config as a build-time
dependency. run implies a run-time
dependency and both implies both run-time and
build-time dependencies.purePossible arguments: (none), ffiUses lang/pure. Largely used
for building related pure ports.
With the ffi argument, it implies devel/pure-ffi as a run-time
dependency.pyqtPossible arguments: (none), 4,
5Uses PyQt. If the port is part
of PyQT itself, set PYQT_DIST. Use
USE_PYQT to select the components the port
needs. The available components are:coredbusdbussupportdemodesignerdesignerplugindocguimultimedianetworkopenglqscintilla2sipsqlsvgtestwebkitxmlxmlpatternsThese components are only available with
PyQT4:assistantdeclarativehelpphononscriptscripttoolsThese components are only available with
PyQT5:multimediawidgetsprintsupportqmlserialportwebkitwidgetswidgetsThe default dependency for each component is build- and
run-time, to select only build or run, add
_build or _run to the
component name. For example:USES= pyqt
USE_PYQT= core doc_build designer_runpythonPossible arguments: (none),
X.Y,
X.Y+,
-X.Y,
X.Y-Z.A,
patch,
build, run,
testUses Python. A supported version
or version range can be specified. If Python is only needed at
build time, run time or for the tests, it can be set as a build,
run or test dependency with build,
run, or test. If Python
is also needed during the patch phase, use
patch. See
for more information.PYTHON_NO_DEPENDS=yes can be used when
the variables exported by the framework are needed but a
dependency on Python is not. It can
happen when using with USES=shebangfix,
and the goal is only to fix the shebangs but not add a
dependency on Python.qmailPossible arguments: (none), build,
run, both,
varsUses mail/qmail. With the
build argument, it implies
qmail as a build-time dependency.
run implies a run-time dependency. Using no
argument or the both argument implies both
run-time and build-time dependencies. vars
will only set QMAIL variables for the port to use.qmakePossible arguments: (none), norecursive,
outsource, no_env,
no_configureUses QMake for configuring. For
more information see .qtPossible arguments: 5,
no_envAdd dependency on Qt components.
no_env is passed directly to
USES= qmake. See
for more information.qt-distPossible arguments: (none) or 5 and
(none) or one of 3d,
activeqt, androidextras,
base, canvas3d,
charts, connectivity,
datavis3d, declarative,
doc, gamepad,
graphicaleffects,
imageformats, location,
macextras, multimedia,
networkauth, purchasing,
quickcontrols2,
quickcontrols,
remoteobjects, script,
scxml, sensors,
serialbus, serialport,
speech, svg,
tools, translations,
virtualkeyboard, wayland,
webchannel, webengine,
websockets, webview,
winextras, x11extras,
xmlpatternsProvides support for building Qt
5 components. It takes care of setting up the
appropriate configuration environment for the port to
build.Building Qt 5 ComponentsThe port is Qt 5's
networkauth component, which is part of
the networkauth distribution file.PORTNAME= networkauth
DISTVERSION= ${QT5_VERSION}
USES= qt-dist:5If PORTNAME does not match the
component name, it can be passed as an argument to
qt-dist.Building Qt 5 Components with Different NamesThe port is Qt 5's
gui component, which is part of the
base distribution file.PORTNAME= gui
DISTVERSION= ${QT5_VERSION}
USES= qt-dist:5,basereadlinePossible arguments: (none), portUses readline as a library
dependency, and sets CPPFLAGS and
LDFLAGS as necessary. If the
port argument is used or if readline is not
present in the base system, add a dependency on devel/readlinesambaPossible arguments: build,
env, lib,
runHandle dependency on Samba.
env will not add any dependency and only set
up the variables. build and
run will add build-time and run-time
dependency on smbd. lib
will add a dependency on libsmbclient.so.
The variables that are exported are:SAMBAPORTThe origin of the default
Samba port.SAMBAINCLUDESThe location of the Samba
header files.SAMBALIBSThe directory where the
Samba shared libraries are
available.sconsPossible arguments: (none)Provide support for the use of devel/scons. See for more information.shared-mime-infoPossible arguments: (none)Uses update-mime-database from
misc/shared-mime-info. This uses
will automatically add a post-install step in such a way that
the port itself still can specify there own post-install step if
needed. It also add an @shared-mime-info
entry to the plist.shebangfixPossible arguments: (none)A lot of software uses incorrect locations for script
interpreters, most notably /usr/bin/perl
and /bin/bash. The shebangfix macro fixes
shebang lines in scripts listed in
SHEBANG_REGEX,
SHEBANG_GLOB, or
SHEBANG_FILES.SHEBANG_REGEXContains one extended regular
expressions, and is used with the
-iregex argument of &man.find.1;. See
.SHEBANG_GLOBContains a list of patterns used with the
-name argument of &man.find.1;. See
.SHEBANG_FILESContains a list of files or &man.sh.1; globs. The
shebangfix macro is run from ${WRKSRC},
so SHEBANG_FILES can contain paths that
are relative to ${WRKSRC}. It can also
deal with absolute paths if files outside of
${WRKSRC} require patching. See .Currently
Bash,
Java, Ksh,
Lua,
Perl, PHP,
Python,
Ruby, Tcl,
and Tk are supported by
default.There are three configuration variables:SHEBANG_LANGThe list of supported interpreters.interp_CMDThe path to the command interpreter on &os;. The
default value is
${LOCALBASE}/bin/interp.interp_OLD_CMDThe list of wrong invocations of interpreters. These
are typically obsolete paths, or paths used on other
operating systems that are incorrect on &os;. They
will be replaced by the correct path in
interp_CMD.These will always be part of
interp_OLD_CMD:
"/usr/bin/env
interp"
/bin/interp
/usr/bin/interp
/usr/local/bin/interp.interp_OLD_CMD
contain multiple values. Any entry with spaces must be
quoted. See .The fixing of shebangs is done during the
patch phase. If scripts are
created with incorrect shebangs during the
build phase, the build process (for
example, the configure script, or the
Makefiles) must be patched or given the
right path (for example, with
CONFIGURE_ENV,
CONFIGURE_ARGS,
MAKE_ENV, or MAKE_ARGS)
to generate the right shebangs.Correct paths for supported interpreters
are available in
interp_CMD.When used with USES=python,
and the aim is only to fix the shebangs but a dependency on
Python itself is not wanted, use
PYTHON_NO_DEPENDS=yes.Adding Another Interpreter to
USES=shebangfixTo add another interpreter, set
SHEBANG_LANG. For example:SHEBANG_LANG= luaSpecifying all the Paths When Adding an Interpreter to
USES=shebangfixIf it was not already defined, and there were no default
values for
interp_OLD_CMD
and interp_CMD
the Ksh entry could be defined
as:SHEBANG_LANG= ksh
ksh_OLD_CMD= "/usr/bin/env ksh" /bin/ksh /usr/bin/ksh
ksh_CMD= ${LOCALBASE}/bin/kshAdding a Strange Location for an InterpreterSome software uses strange locations for an interpreter.
For example, an application might expect
Python to be located in
/opt/bin/python2.7. The strange path to
be replaced can be declared in the port
Makefile:python_OLD_CMD= /opt/bin/python2.7USES=shebangfix with
SHEBANG_REGEXTo fix all the files in
${WRKSRC}/scripts ending in
.pl, .sh, or
.cgi do:USES= shebangfix
SHEBANG_REGEX= ./scripts/.*\.(sh|pl|cgi)SHEBANG_REGEX is used by running
find -E, which uses modern regular
expressions also known as extended regular expressions. See
&man.re.format.7; for more information.USES=shebangfix with
SHEBANG_GLOBTo fix all the files in ${WRKSRC}
ending in .pl or
.sh, do:USES= shebangfix
SHEBANG_GLOB= *.sh *.plUSES=shebangfix with
SHEBANG_FILESTo fix the files script/foobar.pl and
script/*.sh in
${WRKSRC}, do:USES= shebangfix
SHEBANG_FILES= scripts/foobar.pl scripts/*.shsqlitePossible arguments: (none), 2,
3Add a dependency on SQLite. The
default version used is 3, but version 2 is also possible using
the :2 modifier.sslPossible arguments: (none), build,
runProvide support for OpenSSL.
A build- or run-time only dependency can be specified using
build or run.
These variables are available for the port's use, they are also
added to MAKE_ENV:OPENSSLBASEPath to the OpenSSL installation base.OPENSSLDIRPath to OpenSSL's
configuration files.OPENSSLLIBPath to the OpenSSL
libraries.OPENSSLINCPath to the OpenSSL
includes.OPENSSLRPATHIf defined, the path the linker needs to use to find
the OpenSSL libraries.If a port does not build with an
OpenSSL flavor, set the
BROKEN_SSL variable, and possibly the
BROKEN_SSL_REASON_flavor:BROKEN_SSL= libressl
BROKEN_SSL_REASON_libressl= needs features only available in OpenSSLtarPossible arguments: (none), Z,
bz2, bzip2,
lzma, tbz,
tbz2,
tgz, txz,
xzSet EXTRACT_SUFX to
.tar, .tar.Z,
.tar.bz2, .tar.bz2,
.tar.lzma, .tbz,
.tbz2,
.tgz, .txz or
.tar.xz respectively.tclPossible arguments: version,
wrapper, build,
run, teaAdd a dependency on Tcl. A
specific version can be requested using
version. The version can be empty,
one or more exact version numbers (currently
84, 85, or
86), or a minimal version number (currently
84+, 85+ or
86+). To only request a non version specific
wrapper, use wrapper. A build- or run-time
only dependency can be specified using build
or run. To build the port using the
Tcl Extension Architecture, use
tea. After including
bsd.port.pre.mk the port can inspect the
results using these variables:TCL_VER: chosen major.minor version
of TclTCLSH: full path of the
Tcl interpreterTCL_LIBDIR: path of the
Tcl librariesTCL_INCLUDEDIR: path of the
Tcl C header filesTK_VER: chosen major.minor version of
TkWISH: full path of the
Tk interpreterTK_LIBDIR: path of the
Tk librariesTK_INCLUDEDIR: path of the
Tk C header filesterminfoPossible arguments: (none)Adds @terminfo
to the plist. Use when the port installs
*.terminfo files
in ${PREFIX}/share/misc.tkSame as arguments for tclSmall wrapper when using both Tcl
and Tk. The same variables are
returned as when using Tcl.uidfixPossible arguments: (none)Changes some default behavior (mostly variables) of
the build system to allow installing this port as a normal
user. Try this in the port before using USES=fakeroot or
patching.uniquefilesPossible arguments: (none), dirsMake files or directories 'unique', by adding a prefix or
suffix. If the dirs argument is used, the
port needs a prefix (and only a prefix) based on
UNIQUE_PREFIX for standard directories
DOCSDIR, EXAMPLESDIR,
DATADIR, WWWDIR,
ETCDIR. These variables are available for
ports:UNIQUE_PREFIX: The prefix to be used
for directories and files. Default:
${PKGNAMEPREFIX}.UNIQUE_PREFIX_FILES: A list of files
that need to be prefixed. Default: empty.UNIQUE_SUFFIX: The suffix to be used
for files. Default:
${PKGNAMESUFFIX}.UNIQUE_SUFFIX_FILES: A list of files
that need to be suffixed. Default: empty.varnishPossible arguments: 4,
5Handle dependencies on Varnish
Cache. 4 will add a
dependency on www/varnish4.
5 will add a dependency on www/varnish5.webpluginPossible arguments: (none), ARGSAutomatically create and remove symbolic links for each
application that supports the webplugin framework.
ARGS can be one of:gecko: support plug-ins based on
Geckonative: support plug-ins for Gecko,
Opera, and WebKit-GTKlinux: support Linux plug-insall (default, implicit): support all
plug-in types(individual entries): support only the browsers
listedThese variables can be adjusted:WEBPLUGIN_FILES: No default, must be
set manually. The plug-in files to install.WEBPLUGIN_DIR: The directory to
install the plug-in files to, default
PREFIX/lib/browser_plugins/WEBPLUGIN_NAME.
Set this if the port installs plug-in files outside of the
default directory to prevent broken symbolic links.WEBPLUGIN_NAME: The final directory
to install the plug-in files into, default
PKGBASE.xfce
- Possible arguments: (none), gtk3
+ Possible arguments: (none), gtk2Provide support for Xfce related
ports. See for details.
- The gtk3 argument specifies that the port
- requires GTK3 support. It adds
+ The gtk2 argument specifies that the port
+ requires GTK2 support. It adds
additional features provided by some core components, for
example, x11/libxfce4menu and
x11-wm/xfce4-panel.xorgPossible arguments: (none)Provides an easy way to depend on
X.org components. The components
should be listed in USE_XORG. The available
components are:
Available X.Org ComponentsNameDescriptiondmxDMX extension libraryfontencThe fontenc LibraryfontutilCreate an index of X font files in a
directoryiceInter Client Exchange library for X11libfsThe FS libraryoldxOld X librarypciaccessGeneric PCI access librarypixmanLow-level pixel manipulation librarysmSession Management library for X11x11X11 libraryxauAuthentication Protocol library for X11xawX Athena Widgets libraryxaw6X Athena Widgets libraryxaw7X Athena Widgets libraryxbitmapsX.Org bitmaps dataxcbThe X protocol C-language Binding (XCB)
libraryxcompositeX Composite extension libraryxcursorX client-side cursor loading libraryxdamageX Damage extension libraryxdmcpX Display Manager Control Protocol
libraryxevieThe Xevie libraryxextX11 Extension libraryxfixesX Fixes extension libraryxfontX font libraryxfont2X font library version 2.xxfontcacheThe Xfontcache libraryxftClient-sided font API for X applicationsxiX Input extension libraryxineramaX11 Xinerama libraryxkbfileXKB file libraryxkbuiThe xkbui libraryxmuX Miscellaneous Utilities librariesxmuuX Miscellaneous Utilities librariesxorg-macrosX.Org development aclocal macrosxorg-serverX.Org X server and related programsxorgprotoX.Org protocol headersxpX print libraryxpmX Pixmap libraryxprintapputilThe XprintAppUtil libraryxprintutilThe XprintUtil libraryxrandrX Resize and Rotate extension libraryxrenderX Render extension libraryxresX Resource usage libraryxscrnsaverThe XScrnSaver libraryxshmfenceShared memory 'SyncFence' synchronization
primitivextX Toolkit libraryxtransAbstract network code for XxtrapThe XTrap libraryxtstX Test extensionxvX Video Extension libraryxvmcX Video Extension Motion Compensation
libraryxxf86dgaX DGA Extensionxxf86miscX XF86-Misc Extensionxxf86vmX Vidmode Extension
xorg-catPossible arguments: app, data,
doc, driver,
font, lib, proto,
util, xserver and (none) or one off
autotools (default), mesonProvide support for building Xorg
components. It takes care of setting up common dependencies and an
appropriate configuration environment needed. This is intended only
for Xorg components.The category has to match upstream categories.The second argument is the build system to use.
autotools is the default, but
meson is also supported.zipPossible arguments: (none),
infozipIndicates that the distribution files use the ZIP
compression algorithm. For files using the InfoZip algorithm
the infozip argument must be passed to set
the appropriate dependencies.zopePossible arguments: (none)Uses
www/zopeXY.
Mostly used
for building zope related ports.
ZOPE_VERSION can be used by a port to
indicate that a specific version of
zope shall be used.