This is a longer description of the port. One to a few paragraphs concisely explaining what the port does is sufficient.

A well-written pkg-descr describes the port completely enough that users would not have to consult the documentation or visit the website to understand what the software does, how it can be useful, or what particularly nice features it has. Mentioning certain requirements like a graphical toolkit, heavy dependencies, runtime environment, or implementation languages help users decide whether this port will work for them.

Include a URL to the official WWW homepage. Prepend one of the websites (pick the most common one) with WWW: (followed by single space) so that automated tools will work correctly. If the URI is the root of the website or directory, it must be terminated with a slash.

This example shows how pkg-descr looks:

This is a port of oneko, in which a cat chases a poor mouse all over
the screen.
 :
(etc.)

WWW: http://www.oneko.org/

This file lists all the files installed by the port. It is also called the “packing list” because the package is generated by packing the files listed here. The pathnames are relative to the installation prefix (usually /usr/local).

Here is a small example:

bin/oneko
man/man1/oneko.1.gz
lib/X11/app-defaults/Oneko
lib/X11/oneko/cat1.xpm
lib/X11/oneko/cat2.xpm
lib/X11/oneko/mouse.xpm

Refer to the pkg-create(8) manual page for details on the packing list.

There is only one case when pkg-plist can be omitted from a port. If the port installs just a handful of files, list them in PLIST_FILES, within the port's Makefile. For instance, we could get along without pkg-plist in the above oneko port by adding these lines to the Makefile:

PLIST_FILES=	bin/oneko \
		man/man1/oneko.1.gz \
		lib/X11/app-defaults/Oneko \
		lib/X11/oneko/cat1.xpm \
		lib/X11/oneko/cat2.xpm \
		lib/X11/oneko/mouse.xpm

The price for this way of listing a port's files and directories is that the keywords described in pkg-create(8) and Section 7.6, “Expanding Package List with Keywords” cannot be used. Therefore, it is suitable only for simple ports and makes them even simpler. At the same time, it has the advantage of reducing the number of files in the ports collection. Please consider using this technique before resorting to pkg-plist.

Later we will see how pkg-plist and PLIST_FILES can be used to fulfill more sophisticated tasks.

Patch files are stored in PATCHDIR, usually files/, from where they will be automatically applied. All patches must be relative to WRKSRC. Typically WRKSRC is a subdirectory of WRKDIR, the directory where the distfile is extracted. Use make -V WRKSRC to see the actual path. The patch names are to follow these rules:

Minimize the amount of non-functional whitespace changes in patches. It is common in the Open Source world for projects to share large amounts of a code base, but obey different style and indenting rules. When taking a working piece of functionality from one project to fix similar areas in another, please be careful: the resulting patch may be full of non-functional changes. It not only increases the size of the ports repository but makes it hard to find out what exactly caused the problem and what was changed at all.

If a file must be deleted, do it in the post-extract target rather than as part of the patch.

Patches are saved into files named patch-* where * indicates the pathname of the file that is patched, such as patch-Imakefile or patch-src-config.h.

After the file has been modified, diff(1) is used to record the differences between the original and the modified version. -u causes diff(1) to produce “unified” diffs, the preferred form.

% diff -u file.orig file > patch-pathname-file

When generating patches for new, added files, -N is used to tell diff(1) to treat the non-existent original file as if it existed but was empty:

% diff -u -N newfile.orig newfile > patch-pathname-newfile

Do not add $FreeBSD$ RCS strings in patches. When patches are added to the Subversion repository with svn add, the fbsd:nokeywords property is set to yes automatically so keywords in the patch are not modified when committed. The property can be added manually with svn propset fbsd:nokeywords yes files....

Using the recurse (-r) option to diff(1) to generate patches is fine, but please look at the resulting patches to make sure there is no unnecessary junk in there. In particular, diffs between two backup files, Makefiles when the port uses Imake or GNU configure, etc., are unnecessary and have to be deleted. If it was necessary to edit configure.in and run autoconf to regenerate configure, do not take the diffs of configure (it often grows to a few thousand lines!). Instead, define USE_AUTOTOOLS=autoconf:261 and take the diffs of configure.in.

Simple replacements can be performed directly from the port Makefile using the in-place mode of sed(1). This is useful when changes use the value of a variable:

post-patch:
      @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README

Quite often, software being ported uses the CR/LF convention in source files. This may cause problems with further patching, compiler warnings, or script execution (like /bin/sh^M not found.) To quickly convert all files from CR/LF to just LF, add this entry to the port Makefile:

USES=	dos2unix

A list of specific files to convert can be given:

USES=	dos2unix
DOS2UNIX_FILES=	util.c util.h

Use DOS2UNIX_REGEX to convert a group of files across subdirectories. Its argument is a find(1)-compatible regular expression. More on the format is in re_format(7). This option is useful for converting all files of a given extension. For example, convert all source code files, leaving binary files intact:

USES=	dos2unix
DOS2UNIX_REGEX=	.*\.([ch]|cpp)

A similar option is DOS2UNIX_GLOB, which runs find for each element listed in it.

USES=	dos2unix
DOS2UNIX_GLOB=	*.c *.cpp *.h

Set PORTNAME to the base name of the port, and PORTVERSION to the version number of the port.

Two optional variables, PKGNAMEPREFIX and PKGNAMESUFFIX, are combined with PORTNAME and PORTVERSION to form PKGNAME as ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. Make sure this conforms to our guidelines for a good package name. In particular, the use of a hyphen (-) in PORTVERSION is not allowed. Also, if the package name has the language- or the -compiled.specifics part (see below), use PKGNAMEPREFIX and PKGNAMESUFFIX, respectively. Do not make them part of PORTNAME.

These are the conventions to follow when naming packages. This is to make the package directory easy to scan, as there are already thousands of packages and users are going to turn away if they hurt their eyes!

Package names take the form of language_region-name-compiled.specifics-version.numbers.

The package name is defined as ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. Make sure to set the variables to conform to that format.

Here are some (real) examples on how to convert the name as called by the software authors to a suitable package name:

If there is absolutely no trace of version information in the original source and it is unlikely that the original author will ever release another version, just set the version string to 1.0 (like the piewm example above). Otherwise, ask the original author or use the date string the source file was released on (0.0.yyyy.mm.dd) as the version.

When a package is created, it is put under /usr/ports/packages/All and links are made from one or more subdirectories of /usr/ports/packages. The names of these subdirectories are specified by the variable CATEGORIES. It is intended to make life easier for the user when he is wading through the pile of packages on the FTP site or the CDROM. Please take a look at the current list of categories and pick the ones that are suitable for the port.

This list also determines where in the ports tree the port is imported. If there is more than one category here, the port files must be put in the subdirectory with the name of the first category. See below for more discussion about how to pick the right categories.

Here is the current list of port categories. Those marked with an asterisk (*) are virtual categories—those that do not have a corresponding subdirectory in the ports tree. They are only used as secondary categories, and only for search purposes.

As many of the categories overlap, choosing which of the categories will be the primary category of the port can be tedious. There are several rules that govern this issue. Here is the list of priorities, in decreasing order of precedence:

If the category is not clearly defined, please put a comment to that effect in the port submission in the bug database so we can discuss it before we import it. As a committer, send a note to the FreeBSD ports mailing list so we can discuss it first. Too often, new ports are imported to the wrong category only to be moved right away. This causes unnecessary and undesirable bloat in the master source repository.

As the Ports Collection has grown over time, various new categories have been introduced. New categories can either be virtual categories—those that do not have a corresponding subdirectory in the ports tree— or physical categories—those that do. This section discusses the issues involved in creating a new physical category. Read it thouroughly before proposing a new one.

Our existing practice has been to avoid creating a new physical category unless either a large number of ports would logically belong to it, or the ports that would belong to it are a logically distinct group that is of limited general interest (for instance, categories related to spoken human languages), or preferably both.

The rationale for this is that such a change creates a fair amount of work for both the committers and also for all users who track changes to the Ports Collection. In addition, proposed category changes just naturally seem to attract controversy. (Perhaps this is because there is no clear consensus on when a category is “too big”, nor whether categories should lend themselves to browsing (and thus what number of categories would be an ideal number), and so forth.)

Here is the procedure:

Proposing a new virtual category is similar to the above but much less involved, since no ports will actually have to move. In this case, the only patches to include in the PR would be those to add the new category to CATEGORIES of the affected ports.

Occasionally someone proposes reorganizing the categories with either a 2-level structure, or some other kind of keyword structure. To date, nothing has come of any of these proposals because, while they are very easy to make, the effort involved to retrofit the entire existing ports collection with any kind of reorganization is daunting to say the very least. Please read the history of these proposals in the mailing list archives before posting this idea. Furthermore, be prepared to be challenged to offer a working prototype.

DISTNAME is the name of the port as called by the authors of the software. DISTNAME defaults to ${PORTNAME}-${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}, and DISTVERSION defaults to ${PORTVERSION} so override it only if necessary. DISTNAME is only used in two places. First, the distribution file list (DISTFILES) defaults to ${DISTNAME}${EXTRACT_SUFX}. Second, the distribution file is expected to extract into a subdirectory named WRKSRC, which defaults to work/${DISTNAME}.

Some vendor's distribution names which do not fit into the ${PORTNAME}-${PORTVERSION}-scheme can be handled automatically by setting DISTVERSION. PORTVERSION will be derived from it automatically.

Record the directory part of the FTP/HTTP-URL pointing at the original tarball in MASTER_SITES. Do not forget the trailing slash (/)!

The make macros will try to use this specification for grabbing the distribution file with FETCH if they cannot find it already on the system.

It is recommended that multiple sites are included on this list, preferably from different continents. This will safeguard against wide-area network problems. We are even planning to add support for automatically determining the closest master site and fetching from there; having multiple sites will go a long way towards helping this effort.

If the original tarball is part of one of the popular archives such as SourceForge, GNU, or Perl CPAN, it may be possible refer to those sites in an easy compact form using predefined macros (for example, SF, GNU or CPAN). Set MASTER_SITES to one of these values. Here is an example:

MASTER_SITES=	GNU/make

The older expanded format can still be used, although there really is no reason to do so:

MASTER_SITES=		${MASTER_SITE_GNU}
	MASTER_SITE_SUBDIR=	make

These values and variables are defined in /usr/ports/Mk/bsd.sites.mk. There are new entries added all the time, so make sure to check the latest version of this file before submitting a port.

Several magic macros exist for popular sites with a predictable directory structure. For these, just use the abbreviation and the system will try to guess the correct subdirectory automatically.

MASTER_SITES=	SF

If the guess is incorrect, it can be overridden as follows.

MASTER_SITES=	SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION}

This can also be written as

MASTER_SITES=	SF
	MASTER_SITE_SUBDIR=	stardict/WyabdcRealPeopleTTS/${PORTVERSION}

PORTNAME=	pkg
	    PORTVERSION=	1.2.7

	    USE_GITHUB=	yes
	    GH_ACCOUNT=	freebsd
	    GH_COMMIT=	f53e577

PORTNAME=	pkg-devel
	    PORTVERSION=	1.3.0.a.20140411

	    USE_GITHUB=	yes
	    GH_ACCOUNT=	freebsd
	    GH_PROJECT=	pkg
	    GH_TAGNAME=	${GH_COMMIT}
	    GH_COMMIT=	6dbb17b

If there is one distribution file, and it uses an odd suffix to indicate the compression mechanism, set EXTRACT_SUFX.

For example, if the distribution file was named foo.tar.gzip instead of the more normal foo.tar.gz, write:

DISTNAME=	foo
	EXTRACT_SUFX=	.tar.gzip

The USES=tar[:xxx], USES=lha or USES=zip automatically set EXTRACT_SUFX to the most common archives extensions as necessary, see Chapter 15, Values of USES for more details. If neither of these are set then EXTRACT_SUFX defaults to .tar.gz.

Sometimes the names of the files to be downloaded have no resemblance to the name of the port. For example, it might be called source.tar.gz or similar. In other cases the application's source code might be in several different archives, all of which must be downloaded.

If this is the case, set DISTFILES to be a space separated list of all the files that must be downloaded.

DISTFILES=	source1.tar.gz source2.tar.gz

If not explicitly set, DISTFILES defaults to ${DISTNAME}${EXTRACT_SUFX}.

If only some of the DISTFILES must be extracted—for example, one of them is the source code, while another is an uncompressed document—list the filenames that must be extracted in EXTRACT_ONLY.

DISTFILES=	source.tar.gz manual.html
	EXTRACT_ONLY=	source.tar.gz

When none of the DISTFILES need to be uncompressed, set EXTRACT_ONLY to the empty string.

EXTRACT_ONLY=

If the port requires some additional patches that are available by FTP or HTTP, set PATCHFILES to the names of the files and PATCH_SITES to the URL of the directory that contains them (the format is the same as MASTER_SITES).

If the patch is not relative to the top of the source tree (that is, WRKSRC) because it contains some extra pathnames, set PATCH_DIST_STRIP accordingly. For instance, if all the pathnames in the patch have an extra foozolix-1.0/ in front of the filenames, then set PATCH_DIST_STRIP=-p1.

Do not worry if the patches are compressed; they will be decompressed automatically if the filenames end with .Z, .gz, .bz2 or .xz.

If the patch is distributed with some other files, such as documentation, in a gzipped tarball, using PATCHFILES is not possible. If that is the case, add the name and the location of the patch tarball to DISTFILES and MASTER_SITES. Then, use EXTRA_PATCHES to point to those files and bsd.port.mk will automatically apply them. In particular, do not copy patch files into ${PATCHDIR}. That directory may not be writable.

PATCHFILES=	patch1 patch2:-p1

PATCHFILES=	patch2:-p1:source2

(Consider this to be a somewhat “advanced topic”; those new to this document may wish to skip this section at first).

This section has information on the fetching mechanism known as both MASTER_SITES:n and MASTER_SITES_NN. We will refer to this mechanism as MASTER_SITES:n.

A little background first. OpenBSD has a neat feature inside DISTFILES and PATCHFILES which allows files and patches to be postfixed with :n identifiers. Here, n can be both [0-9] and denote a group designation. For example:

DISTFILES=	alpha:0 beta:1

In OpenBSD, distribution file alpha will be associated with variable MASTER_SITES0 instead of our common MASTER_SITES and beta with MASTER_SITES1.

This is a very interesting feature which can decrease that endless search for the correct download site.

Just picture 2 files in DISTFILES and 20 sites in MASTER_SITES, the sites slow as hell where beta is carried by all sites in MASTER_SITES, and alpha can only be found in the 20th site. It would be such a waste to check all of them if the maintainer knew this beforehand, would it not? Not a good start for that lovely weekend!

Now that you have the idea, just imagine more DISTFILES and more MASTER_SITES. Surely our “distfiles survey meister” would appreciate the relief to network strain that this would bring.

In the next sections, information will follow on the FreeBSD implementation of this idea. We improved a bit on OpenBSD's concept.

MASTER_SITES=	ftp://ftp.example1.com/:source1 \
	    ftp://ftp.example2.com/:source2
	    DISTFILES=	source1.tar.gz:source1 \
	    source2.tar.gz:source2

MASTER_SITES=	ftp://ftp.example1.com/:source1 \
	    ftp://ftp.example2.com/:source2
	    DISTFILES=	source1.tar.gz:source1 \
	    source2.tar.gz:source2 \
	    source3.tar.gz:source2

Do not let the port clutter /usr/ports/distfiles. If the port requires a lot of files to be fetched, or contains a file that has a name that might conflict with other ports (for example, Makefile), set DIST_SUBDIR to the name of the port (${PORTNAME} or ${PKGNAMEPREFIX}${PORTNAME} are fine). This will change DISTDIR from the default /usr/ports/distfiles to /usr/ports/distfiles/DIST_SUBDIR, and in effect puts everything that is required for the port into that subdirectory.

It will also look at the subdirectory with the same name on the backup master site at ftp.FreeBSD.org. (Setting DISTDIR explicitly in Makefile will not accomplish this, so please use DIST_SUBDIR.)

If the port uses binary distfiles and has a license that requires that the source code is provided with packages distributed in binary form, like GPL, ALWAYS_KEEP_DISTFILES will instruct the FreeBSD build cluster to keep a copy of the files specified in DISTFILES. Users of these ports will generally not need these files, so it is a good idea to only add the source distfiles to DISTFILES when PACKAGE_BUILDING is defined.

.if defined(PACKAGE_BUILDING)
	  DISTFILES+=		foo.tar.gz
	  ALWAYS_KEEP_DISTFILES=	yes
	  .endif

When adding extra files to DISTFILES, make sure to also add them to distinfo. Also, the additional files will normally be extracted into WRKDIR as well, which for some ports may lead to undesirable side effects and require special handling.

This variable specifies the shared libraries this port depends on. It is a list of lib:dir tuples where lib is the name of the shared library, dir is the directory in which to find it in case it is not available. For example,

LIB_DEPENDS=   libjpeg.so:${PORTSDIR}/graphics/jpeg

will check for a shared jpeg library with any version, and descend into the graphics/jpeg subdirectory of the ports tree to build and install it if it is not found.

The dependency is checked twice, once from within the build target and then from within the install target. Also, the name of the dependency is put into the package so that pkg install (see pkg-install(8)) will automatically install it if it is not on the user's system.

This variable specifies executables or files this port depends on during run-time. It is a list of path:dir[:target] tuples where path is the name of the executable or file, dir is the directory in which to find it in case it is not available, and target is the target to call in that directory. If path starts with a slash (/), it is treated as a file and its existence is tested with test -e; otherwise, it is assumed to be an executable, and which -s is used to determine if the program exists in the search path.

For example,

RUN_DEPENDS=	${LOCALBASE}/news/bin/innd:${PORTSDIR}/news/inn \
	xmlcatmgr:${PORTSDIR}/textproc/xmlcatmgr

will check if the file or directory /usr/local/news/bin/innd exists, and build and install it from the news/inn subdirectory of the ports tree if it is not found. It will also see if an executable called xmlcatmgr is in the search path, and descend into textproc/xmlcatmgr to build and install it if it is not found.

/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin

The dependency is checked from within the install target. Also, the name of the dependency is put into the package so that pkg install (see pkg-install(8)) will automatically install it if it is not on the user's system. The target part can be omitted if it is the same as DEPENDS_TARGET.

A quite common situation is when RUN_DEPENDS is literally the same as BUILD_DEPENDS, especially if ported software is written in a scripted language or if it requires the same build and run-time environment. In this case, it is both tempting and intuitive to directly assign one to the other:

RUN_DEPENDS=	${BUILD_DEPENDS}

However, such assignment can pollute run-time dependencies with entries not defined in the port's original BUILD_DEPENDS. This happens because of make(1)'s lazy evaluation of variable assignment. Consider a Makefile with USE_*, which are processed by ports/Mk/bsd.*.mk to augment initial build dependencies. For example, USES= gmake adds devel/gmake to BUILD_DEPENDS. To prevent such additional dependencies from polluting RUN_DEPENDS, take care to assign with expansion, that is, expand the value before assigning it to the variable:

RUN_DEPENDS:=	${BUILD_DEPENDS}

This variable specifies executables or files this port requires to build. Like RUN_DEPENDS, it is a list of path:dir[:target] tuples. For example,

BUILD_DEPENDS=	unzip:${PORTSDIR}/archivers/unzip

will check for an executable called unzip, and descend into the archivers/unzip subdirectory of the ports tree to build and install it if it is not found.

This variable specifies executables or files this port requires to fetch. Like the previous two, it is a list of path:dir[:target] tuples. For example,

FETCH_DEPENDS=	ncftp2:${PORTSDIR}/net/ncftp2

will check for an executable called ncftp2, and descend into the net/ncftp2 subdirectory of the ports tree to build and install it if it is not found.

The dependency is checked from within the fetch target. The target part can be omitted if it is the same as DEPENDS_TARGET.

This variable specifies executables or files this port requires for extraction. Like the previous, it is a list of path:dir[:target] tuples. For example,

EXTRACT_DEPENDS=	unzip:${PORTSDIR}/archivers/unzip

will check for an executable called unzip, and descend into the archivers/unzip subdirectory of the ports tree to build and install it if it is not found.

The dependency is checked from within the extract target. The target part can be omitted if it is the same as DEPENDS_TARGET.

This variable specifies executables or files this port requires to patch. Like the previous, it is a list of path:dir[:target] tuples. For example,

PATCH_DEPENDS=	${NONEXISTENT}:${PORTSDIR}/java/jfc:extract

will descend into the java/jfc subdirectory of the ports tree to extract it.

The dependency is checked from within the patch target. The target part can be omitted if it is the same as DEPENDS_TARGET.

Parameters can be added to define different features and dependencies used by the port. They are specified by adding this line to the Makefile:

USES= feature[:arguments]

For the complete list of values, please see Chapter 15, Values of USES.

Several variables exist to define common dependencies shared by many ports. Their use is optional, but helps to reduce the verbosity of the port Makefiles. Each of them is styled as USE_*. These variables may be used only in the port Makefiles and ports/Mk/bsd.*.mk. They are not meant for user-settable options — use PORT_OPTIONS for that purpose.

USE_GCC=X.Y

Variables related to gmake and configure are described in Section 6.5, “Building Mechanisms”, while autoconf, automake and libtool are described in Section 6.6, “Using GNU Autotools”. Perl related variables are described in Section 6.8, “Using Perl”. X11 variables are listed in Section 6.9, “Using X11”. Section 6.10, “Using GNOME” deals with GNOME and Section 6.12, “Using KDE” with KDE related variables. Section 6.13, “Using Java” documents Java variables, while Section 6.14, “Web Applications, Apache and PHP” contains information on Apache, PHP and PEAR modules. Python is discussed in Section 6.15, “Using Python”, while Ruby in Section 6.18, “Using Ruby”. Section 6.19, “Using SDL” provides variables used for SDL applications and finally, Section 6.23, “Using Xfce” contains information on Xfce.

A minimal version of a dependency can be specified in any *_DEPENDS except LIB_DEPENDS using this syntax:

p5-Spiffy>=0.26:${PORTSDIR}/devel/p5-Spiffy

The first field contains a dependent package name, which must match the entry in the package database, a comparison sign, and a package version. The dependency is satisfied if p5-Spiffy-0.26 or newer is installed on the machine.

As mentioned above, the default target to call when a dependency is required is DEPENDS_TARGET. It defaults to install. This is a user variable; it is never defined in a port's Makefile. If the port needs a special way to handle a dependency, use the :target part of *_DEPENDS instead of redefining DEPENDS_TARGET.

When running make clean, the port dependencies are automatically cleaned too. If this is not desirable, define NOCLEANDEPENDS in the environment. This may be particularly desirable if the port has something that takes a long time to rebuild in its dependency list, such as KDE, GNOME or Mozilla.

To depend on another port unconditionally, use the variable ${NONEXISTENT} as the first field of BUILD_DEPENDS or RUN_DEPENDS. Use this only when the source of the other port is needed. Compilation time can be saved by specifying the target too. For instance

BUILD_DEPENDS=	${NONEXISTENT}:${PORTSDIR}/graphics/jpeg:extract

will always descend to the jpeg port and extract it.

The ports building technology does not tolerate circular dependencies. If one is introduced, someone, somewhere in the world, will have their FreeBSD installation broken almost immediately, with many others quickly to follow. These can really be hard to detect. If in doubt, before making that change, make sure to run: cd /usr/ports; make index. That process can be quite slow on older machines, but it may be able to save a large number of people, including yourself, a lot of grief in the process.

Dependencies must be declared either explicitly or by using the OPTIONS framework. Using other methods like automatic detection complicates indexing, which causes problems for port and package management.

.include <bsd.port.pre.mk>

	  .if exists(${LOCALBASE}/bin/foo)
	  LIB_DEPENDS=	libbar.so:${PORTSDIR}/foo/bar
	  .endif

The problem with trying to automatically add dependencies is that files and settings outside an individual port can change at any time. For example: an index is built, then a batch of ports are installed. But one of the ports installs the tested file. The index is now incorrect, because an installed port unexpectedly has a new dependency. The index may still be wrong even after rebuilding if other ports also determine their need for dependencies based on the existence of other files.

OPTIONS_DEFINE=	BAR
	  BAR_DESC=	Calling cellphones via bar

	  BAR_LIB_DEPENDS=	libbar.so:${PORTSDIR}/foo/bar

Testing option variables is the correct method. It will not cause inconsistencies in the index of a batch of ports, provided the options were defined prior to the index build. Simple scripts can then be used to automate the building, installation, and updating of these ports and their packages.

USE_* are set by the port maintainer to define software on which this port depends. A port that needs Firefox would set

USE_FIREFOX=	yes

Some USE_* can accept version numbers or other parameters. For example, a port that requires Apache 2.2 would set

USE_APACHE=	22

For more control over dependencies in some cases, WANT_* are available to more precisely specify what is needed. For example, consider the mail/squirrelmail port. This port needs some PHP modules, which are listed in USE_PHP:

USE_PHP=	session mhash gettext mbstring pcre openssl xml

Those modules may be available in CLI or web versions, so the web version is selected with WANT_*:

WANT_PHP_WEB=	yes

Available USE_* and WANT_* are defined in the files in /usr/ports/Mk.

When using a GNU configure script, keep an eye on which optional features are activated by auto-detection. Explicitly disable optional features that are not needed by adding --without-xxx or --disable-xxx in CONFIGURE_ARGS.

.if ${PORT_OPTIONS:MFOO}
LIB_DEPENDS+=		libfoo.so:${PORTSDIR}/devel/foo
CONFIGURE_ARGS+=	--enable-foo
.endif

In the example above, imagine a library libfoo is installed on the system. The user does not want this application to use libfoo, so he toggled the option off in the make config dialog. But the application's configure script detects the library present in the system and includes its support in the resulting executable. Now when the user decides to remove libfoo from the system, the ports system does not protest (no dependency on libfoo was recorded) but the application breaks.

FOO_LIB_DEPENDS=		libfoo.so:${PORTSDIR}/devel/foo
# Will add --enable-foo / --disable-foo
FOO_CONFIGURE_ENABLE=	foo

.if !empty(VARIABLE:MVALUE)
# as an alternative to
.if ${VARIABLE:MVALUE}

There are some macros to help simplify conditional values which differ based on the options set.

OPTIONS_DEFINE=	OPT1
OPTIONS_SUB=	yes

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
PLIST_SUB+=	OPT1="" NO_OPT1="@comment "
SUB_LIST+=	OPT1="" NO_OPT1="@comment "
.else
PLIST_SUB+=	OPT1="@comment " NO_OPT1=""
SUB_LIST+=	OPT1="@comment " NO_OPT1=""
.endif

OPTIONS_DEFINE=	OPT1
OPT1_USE=	mysql=yes xorg=x11,xextproto,xext,xrandr

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
USE_MYSQL=	yes
USE_XORG=	x11 xextproto xext xrandr
.endif

OPTIONS_DEFINE=	OPT1
OPT1_USE_OFF=	mysql=yes xorg=x11,xextproto,xext,xrandr

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ! ${PORT_OPTIONS:MOPT1}
USE_MYSQL=	yes
USE_XORG=	x11 xextproto xext xrandr
.endif

OPTIONS_DEFINE=	OPT1 OPT2
OPT1_CONFIGURE_ENABLE=	test1 test2
OPT2_CONFIGURE_ENABLE=	test2=exhaustive

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
CONFIGURE_ARGS+=	--enable-test1 --enable-test2
.else
CONFIGURE_ARGS+=	--disable-test1 --disable-test2
.endif

.if ${PORT_OPTIONS:MOPT2}
CONFIGURE_ARGS+=	--enable-test2=exhaustive
.else
CONFIGURE_ARGS+=	--disable-test2
.endif

OPTIONS_DEFINE=	OPT1 OPT2
OPT1_CONFIGURE_WITH=	test1
OPT2_CONFIGURE_WITH=	test2=exhaustive

OPTIONS_DEFINE=	OPT1 OPT2

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
CONFIGURE_ARGS+=	--with-test1
.else
CONFIGURE_ARGS+=	--without-test1
.endif

.if ${PORT_OPTIONS:MOPT2}
CONFIGURE_ARGS+=	--with-test2=exhaustive
.else
CONFIGURE_ARGS+=	--without-test2
.endif

OPTIONS_DEFINE=	OPT1
OPT1_CONFIGURE_ON=	--add-test

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
CONFIGURE_ARGS+=	--add-test
.endif

OPTIONS_DEFINE=	OPT1
OPT1_CONFIGURE_OFF=	--no-test

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ! ${PORT_OPTIONS:MOPT1}
CONFIGURE_ARGS+=	--no-test
.endif

OPTIONS_DEFINE=	OPT1
OPT1_CMAKE_ON=	-DTEST:BOOL=true

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
CMAKE_ARGS+=	-DTEST:BOOL=true
.endif

OPTIONS_DEFINE=	OPT1
OPT1_CMAKE_OFF=	-DTEST:BOOL=false

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ! ${PORT_OPTIONS:MOPT1}
CMAKE_ARGS+=	-DTEST:BOOL=false
.endif

OPTIONS_DEFINE=	OPT1
OPT1_QMAKE_ON=	-DTEST:BOOL=true

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
QMAKE_ARGS+=	-DTEST:BOOL=true
.endif

OPTIONS_DEFINE=	OPT1
OPT1_QMAKE_OFF=	-DTEST:BOOL=false

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ! ${PORT_OPTIONS:MOPT1}
QMAKE_ARGS+=	-DTEST:BOOL=false
.endif

OPTIONS_DEFINE=	OPT1
OPT1_LIB_DEPENDS=	liba.so:${PORTSDIR}/devel/a

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
LIB_DEPENDS+=	liba.so:${PORTSDIR}/devel/a
.endif

OPTIONS_DEFINE=	OPT1
OPT1_LIB_DEPENDS_OFF= liba.so:${PORTSDIR}/devel/a

OPTIONS_DEFINE= OPT1

.include <bsd.port.options.mk>

. if ! ${PORT_OPTIONS:MOPT1}
LIB_DEPENDS+=	liba.so:${PORTSDIR}/devel/a
.endif

ALL_TARGET=	all

DOCS_ALL_TARGET=	doc

DOCS_ALL_TARGET=	doc

OPTIONS_DEFINE=	OPT1
OPT1_USES=	gmake
OPT1_CFLAGS=	-DTEST

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ${PORT_OPTIONS:MOPT1}
USES+=		gmake
CFLAGS+=	-DTEST
.endif

OPTIONS_DEFINE=	OPT1
OPT1_USES_OFF=gmake

OPTIONS_DEFINE=	OPT1

.include <bsd.port.options.mk>

.if ! ${PORT_OPTIONS:MOPT1}
USES+=	gmake
.endif

The variable lists the name of the directory that is created when the application's distfiles are extracted. If our previous example extracted into a directory called foo (and not foo-1.0) write:

WRKSRC=	${WRKDIR}/foo

or possibly

WRKSRC=	${WRKDIR}/${PORTNAME}

If the port does not extract in to a subdirectory at all, then set NO_WRKSUBDIR to indicate that.

NO_WRKSUBDIR=	yes

If the package cannot coexist with other packages (because of file conflicts, runtime incompatibilities, etc.), list the other package names in CONFLICTS_INSTALL. Use shell globs like * and ? here. Enumerate package names in there, not port names or origins. Please make sure that CONFLICTS_INSTALL does not match this port's package itself. Otherwise enforcing its installation with FORCE_PKG_REGISTER will no longer work. CONFLICTS_INSTALL check is done after the build stage and prior to the install stage.

If the port cannot be built when other specific ports are already installed, list the other port names in CONFLICTS_BUILD. Use shell globs like * and ? here. Use package names, not port names or origins. CONFLICTS_BUILD check is done prior to the build stage. Build conflicts are not recorded in the resulting package.

If the port cannot be built if a certain port is already installed and the resulting package cannot coexist with the other package, list the other package name in CONFLICTS. use shell globs like * and ? here. Enumerate package names in there, not port names or origins. Please make sure that CONFLICTS does not match this port's package itself. Otherwise enforcing its installation with FORCE_PKG_REGISTER will no longer work. CONFLICTS check is done prior to the build stage and prior to the install stage.

Use the macros provided in bsd.port.mk to ensure correct modes of files in the port's *-install targets. Set ownership directly in pkg-plist with the corresponding entries, such as @owner owner and @group group. These operators work until being overridden, or until the end of pkg-plist, so do not forget to reset them after they are no longer needed. The default ownership is root:wheel.

These are the install command with all the appropriate flags.

Installed binaries should be stripped. Do not strip binaries manually unless forced to. The INSTALL_PROGRAM macro will install and strip a binary at the same time (see the next section). The INSTALL_LIB macro does the same thing to shared libraries.

When a file must be stripped, but neither INSTALL_PROGRAM nor INSTALL_LIB macros are desirable, ${STRIP_CMD} will strip the program or shared library. This is typically done within the post-install target. For example:

post-install:
	  ${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/xdl

When multiple files need to be stripped:

post-install:
	  .for l in geometry media body track world
	  ${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/lib${PORTNAME}-${l}.so.0
	  .endfor

Use file(1) on a file to determine if it has been stripped. Binaries are reported by file(1) as stripped, or not stripped. Additionally, strip(1) will detect programs that have already been stripped and exit cleanly.

Sometimes, a large number of files must be installed while preserving their hierarchical organization. For example, copying over a whole directory tree from WRKSRC to a target directory under PREFIX. Note that PREFIX, EXAMPLESDIR, DATADIR, and other path variables must always be prepended with STAGEDIR to respect staging (see Section 6.1, “Staging”).

Two macros exist for this situation. The advantage of using these macros instead of cp is that they guarantee proper file ownership and permissions on target files. The first macro, COPYTREE_BIN, will set all the installed files to be executable, thus being suitable for installing into PREFIX/bin. The second macro, COPYTREE_SHARE, does not set executable permissions on files, and is therefore suitable for installing files under PREFIX/share target.

post-install:
	  ${MKDIR} ${STAGEDIR}${EXAMPLESDIR}
	  (cd ${WRKSRC}/examples && ${COPYTREE_SHARE} . ${STAGEDIR}${EXAMPLESDIR})

This example will install the contents of the examples directory in the vendor distfile to the proper examples location of the port.

post-install:
	  ${MKDIR} ${STAGEDIR}${DATADIR}/summer
	  (cd ${WRKSRC}/temperatures && ${COPYTREE_SHARE} "June July August" ${STAGEDIR}${DATADIR}/summer)

And this example will install the data of summer months to the summer subdirectory of a DATADIR.

Additional find arguments can be passed via the third argument to COPYTREE_* macros. For example, to install all files from the first example except Makefiles, one can use these commands.

post-install:
	  ${MKDIR} ${STAGEDIR}${EXAMPLESDIR}
	(cd ${WRKSRC}/examples && \
	${COPYTREE_SHARE} . ${STAGEDIR}${EXAMPLESDIR} "! -name Makefile")

These macros do not add the installed files to pkg-plist. They must be added manually. For optional documentation (PORTDOCS, see Section 5.15.4, “Install Additional Documentation”) and examples (PORTEXAMPLES), the %%PORTDOCS%% or %%PORTEXAMPLES%% prefixes must be prepended in pkg-plist.

If the software has some documentation other than the standard man and info pages that is useful for the user, install it under DOCSDIR This can be done, like the previous item, in the post-install target.

Create a new directory for the port. The directory name is DOCSDIR. This usually equals PORTNAME. However, if the user might want different versions of the port to be installed at the same time, the whole PKGNAME can be used.

Since only the files listed in pkg-plist are installed, it is safe to always install documentation to STAGEDIR (see Section 6.1, “Staging”). Hence .if blocks are only needed when the installed files are large enough to cause significant I/O overhead.

post-install:
	  ${MKDIR} ${STAGEDIR}${DOCSDIR}
	  ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${STAGEDIR}${DOCSDIR}

Here are some handy variables and how they are expanded by default when used in the Makefile:

These variables are exported to PLIST_SUB. Their values will appear there as pathnames relative to PREFIX if possible. That is, share/doc/PORTNAME will be substituted for %%DOCSDIR%% in the packing list by default, and so on. (See more on pkg-plist substitution here.)

All conditionally installed documentation files and directories are included in pkg-plist with the %%PORTDOCS%% prefix, for example:

%%PORTDOCS%%%%DOCSDIR%%/AUTHORS
%%PORTDOCS%%%%DOCSDIR%%/CONTACT

As an alternative to enumerating the documentation files in pkg-plist, a port can set the variable PORTDOCS to a list of file names and shell glob patterns to add to the final packing list. The names will be relative to DOCSDIR. Therefore, a port that utilizes PORTDOCS, and uses a non-default location for its documentation, must set DOCSDIR accordingly. If a directory is listed in PORTDOCS or matched by a glob pattern from this variable, the entire subtree of contained files and directories will be registered in the final packing list. If the DOCS option has been unset then files and directories listed in PORTDOCS would not be installed or added to port packing list. Installing the documentation at PORTDOCS as shown above remains up to the port itself. A typical example of utilizing PORTDOCS looks as follows:

PORTDOCS=	README.* ChangeLog docs/*

Try to let the port put things in the right subdirectories of PREFIX. Some ports lump everything and put it in the subdirectory with the port's name, which is incorrect. Also, many ports put everything except binaries, header files and manual pages in a subdirectory of lib, which does not work well with the BSD paradigm. Many of the files must be moved to one of these directories: etc (setup/configuration files), libexec (executables started internally), sbin (executables for superusers/managers), info (documentation for info browser) or share (architecture independent files). See hier(7) for details; the rules governing /usr pretty much apply to /usr/local too. The exception are ports dealing with USENET “news”. They may use PREFIX/news as a destination for their files.

Some 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.

Whenever 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.

This 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.

This 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.

Files 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.

Set 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.

When 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.

If 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 FreeBSD to redistribute the binary, this variable must indicate so.

A 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.

The 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}
.endif

This 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.

The FreeBSD 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 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.

Several differing make implementations exist. Ported software often requires a particular implementation, like GNU make, known in FreeBSD as gmake, or fmake, the legacy FreeBSD make.

If the port uses GNU make, add gmake to USES. If the legacy FreeBSD make is needed, add fmake there.

MAKE_CMD can be used to reference the specific command configured by the USES setting in the port's Makefile. In rare cases when more than one make implementation is listed in USES, the variables GMAKE (for the GNU version) or FMAKE (for the legacy FreeBSD version) are available. 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 Chapter 15, Values of USES 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.

If 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.

For ports that use CMake, define USES= cmake, or USES= cmake:outsource to build in a separate directory (see below).

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 can be requested by using the :outsource suffix. When enabled, 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:outsource
CMAKE_SOURCE_PATH=	${WRKSRC}/subproject

If the port uses SCons, define USE_SCONS=yes.

To make third party SConstruct respect everything that is passed to SCons in SCONS_ENV (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.

The various GNU autotools provide an abstraction mechanism for building a piece of software over a wide variety of operating systems and machine architectures. Within the Ports Collection, an individual port can make use of these tools via a simple construct:

USE_AUTOTOOLS=	tool[:env] ...

At the time of writing, tool can be one of autoconf, autoheader, automake, aclocal, libtoolize. It can also be one the older legacy of autoconf213, autoheader213, automake14, aclocal14.

env is used to specify that the environmental variables are needed. It also adds a build dependency on the tool. The relevant tool is not ran as part of the run-autotools target.

Multiple tools can be specified at once, either by including them all on a single line, or using the += Makefile construct.

Ports shipping with their own copy of libtool (search for a file named ltmain.sh) need to have USES=libtool. If a port has USE_AUTOTOOLS=libtoolize it probably also needs USES=libtool. See the USES=libtool section in Chapter 15, Values of USES for more details.

Some ports make use of the libltdl.so library package, which is part of the libtool suite. Use of this library does not automatically necessitate the use of libtool itself. If the port needs libltdl.so, add a dependency on it:

LIB_DEPENDS=	libltdl.so:${PORTSDIR}/devel/libltdl

Some ports do not contain a configure script, but do contain an autoconf template in configure.ac. Use these assignments to let autoconf create the configure script, and also have autoheader create template headers for use by the configure script.

USE_AUTOTOOLS=	autoconf[:env]

and

USE_AUTOTOOLS=	autoheader

which also implies the use of autoconf.

The additional optional variables AUTOCONF_ARGS and AUTOHEADER_ARGS can be overridden by the port Makefile if specifically requested. Most ports are unlikely to need this. See bsd.autotools.mk for further details.

Some packages only contain Makefile.am. These have to be converted into Makefile.in using automake, and the further processed by configure to generate an actual Makefile.

Similarly, packages occasionally do not ship with an included aclocal.m4, again required to build the software. This can be achieved with aclocal, which scans configure.ac or configure.in.

aclocal has a similar relationship to automake as autoheader does to autoconf, described in the previous section. aclocal implies the use of automake, thus we have:

USE_AUTOTOOLS=	automake[:env]

and

USE_AUTOTOOLS=	aclocal

As with autoconf and autoheader, both automake and aclocal have optional argument variables, AUTOMAKE_ARGS and ACLOCAL_ARGS respectively, which may be overridden by the port Makefile if required.

If 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=	yes

If 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=	yes

Some software products allow for disabling NLS. For example, through passing --disable-nls 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.mo

In high complexity cases, more advanced techniques may be needed, such as dynamic packing list generation.

There 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.

The X11 implementation available in The Ports Collection is X.Org. If the application depends on X components, set USE_XORG to the list of required components. Available components, at the time of writing, are:

bigreqsproto compositeproto damageproto dmx dmxproto dri2proto dri3proto evieproto fixesproto fontcacheproto fontenc fontsproto fontutil glproto ice inputproto kbproto libfs oldx pciaccess pixman presentproto printproto randrproto recordproto renderproto resourceproto scrnsaverproto sm trapproto videoproto x11 xau xaw xaw6 xaw7 xbitmaps xcb xcmiscproto xcomposite xcursor xdamage xdmcp xevie xext xextproto xf86bigfontproto xf86dgaproto xf86driproto xf86miscproto xf86rushproto xf86vidmodeproto xfixes xfont xfontcache xft xi xinerama xineramaproto xkbfile xkbui xmu xmuu xorg-macros xorg-server xp xpm xprintapputil xprintutil xproto xproxymngproto xrandr xrender xres xscrnsaver xshmfence xt xtrans xtrap xtst xv xvmc xxf86dga xxf86misc xxf86vm.

Always up-to-date list can be found in /usr/ports/Mk/bsd.xorg.mk.

The Mesa Project is an effort to provide free OpenGL implementation. To specify a dependency on various components of this project, use USE_GL. Valid options are: egl, gl, glesv2, glew, glu, glut, glw and linux. For backwards compatibility, the value of yes maps to glu.

USE_XORG=	xrender xft xkbfile xt xaw
USE_GL=		glu

# Use some X11 libraries
USE_XORG=	x11 xpm

If 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:

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.

If the port installs fonts for the X Window System, put them in LOCALBASE/lib/X11/fonts/local.

Some applications require a working X11 display for compilation to succeed. This pose 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=	display

Desktop 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.

DESKTOP_ENTRIES=	"NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify

DESKTOP_ENTRIES=	"ToME" "Roguelike game based on JRR Tolkien's work" \
			"${DATADIR}/xtra/graf/tome-128.png" \
			"tome -v -g" "Application;Game;RolePlaying;" \
			false

The Ports Collection provides support for Qt 4 and Qt 5 frameworks with USE_QTx, where x is 4 or 5. Set USE_QTx to the list of required Qt components (libraries, tools, plugins). The Qt 4 and Qt 5 frameworks are quite similar. The main difference is the set of supported components.

The Qt framework exports a number of variables which can be used by ports, some of them listed below:

When using the Qt framework, 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 ofCONFIGURE_ENV and CONFIGURE_ARGS, set QT_NONSTANDARD.

Individual Qt tool and library dependencies must be specified in USE_QTx. 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, _USE_QT4_ONLY, and _USE_QT5_ONLY in /usr/ports/Mk/bsd.qt.mk):

To determine the libraries an application depends on, run ldd on the main executable after a successful compilation.

USE_QT4=	gui moc_build qmake_build rcc_build uic_build

If the application provides a qmake project file (*.pro), define USES= qmake along with USE_QTx. Note that USES= qmake already implies a build dependency on qmake, therefore the qmake component can be omitted from USE_QTx. Similar to CMake, qmake supports out-of-source builds, which can be enabled by specifying the outsource argument (see USES= qmake example).

USES=			qmake:outsource
USE_QT4=	moc_build

USES=	qmake:outsource
USE_QT5=	buildtools_build

Qt 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:

If the application depends on KDE 4, set USE_KDE4 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, automoc4_build automoc4_run). The most commonly used components are listed below (up-to-date components are documented at the top of /usr/ports/Mk/bsd.kde4.mk):

KDE 4 ports are installed into KDE4_PREFIX. This is achieved by specifying the kdeprefix component, which overrides the default PREFIX. The ports, however, respect any PREFIX set via the MAKEFLAGS environment variable and/or make arguments. Currently KDE4_PREFIX is identical to the default PREFIX, ${LOCALBASE}.

USES=		cmake:outsource
USE_KDE4=	kdelibs kdeprefix automoc4
USE_QT4=	moc_build qmake_build rcc_build uic_build

If 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 one of these versions, define which one. The most current version, and FreeBSD default is java/openjdk6.

Below is the list of all settings a port will receive after setting USE_JAVA:

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:

The related entries are defined in both PLIST_SUB (documented in Section 7.1, “Changing pkg-plist Based on Make Variables”) and SUB_LIST.

When 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 Section 6.5, “Building Mechanisms”.

When 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.jar

When 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 Section 7.1, “Changing pkg-plist Based on Make Variables”) 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 FreeBSD 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 FreeBSD Java Language mailing list.

Although there is a java category for PRs, it refers to the JDK porting effort from the FreeBSD 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 Section 5.3, “Categorization”.

Web 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.

Do not depend on Apache unless the web app explicitly needs Apache. Respect that users may wish to run a web app on different web server than Apache.

Porting 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.

PORTNAME=       Date
PORTVERSION=	1.4.3
CATEGORIES=	devel www pear

MAINTAINER=	example@domain.com
COMMENT=	PEAR Date and Time Zone Classes

USES=	pear

.include <bsd.port.mk>

PORTNAME=	Horde_Core
PORTVERSION=	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>

There 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.

To 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):

The available wxWidgets versions and the corresponding ports in the tree are:

The variables in Table 6.23, “Variables to Select wxWidgets Versions” can be set to one or more of these combinations separated by spaces: