5.9. Dependencies

Many ports depend on other ports. This is a very convenient feature of most Unix-like operating systems, including FreeBSD. Multiple ports can share a common dependency, rather than bundling that dependency with every port or package that needs it. There are seven variables that can be used to ensure that all the required bits will be on the user's machine. There are also some pre-supported dependency variables for common cases, plus a few more to control the behavior of dependencies.

Important:

When software has extra dependencies that provide extra features, the base dependencies listed in *_DEPENDS should include the extra dependencies that would benefit most users. The base dependencies should never be a minimal dependency set. The goal is not to include every dependency possible. Only include those that will benefit most people.

5.9.1. LIB_DEPENDS

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

5.9.2. RUN_DEPENDS

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:news/inn \
		xmlcatmgr: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.

Note:

In this case, innd is actually an executable; if an executable is in a place that is not expected to be in the search path, use the full pathname.

Note:

The official search PATH used on the ports build cluster is

/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, create another variable with the current content of BUILD_DEPENDS and assign it to both BUILD_DEPENDS and RUN_DEPENDS:

MY_DEPENDS=	some:devel/some \
		other:lang/other
BUILD_DEPENDS=	${MY_DEPENDS}
RUN_DEPENDS=	${MY_DEPENDS}

Important:

Do not use := to assign BUILD_DEPENDS to RUN_DEPENDS or vice-versa. All variables are expanded immediately, which is exactly the wrong thing to do and almost always a failure.

5.9.3. 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: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.

Note:

build here means everything from extraction to compilation. The dependency is checked from within the extract target. The target part can be omitted if it is the same as DEPENDS_TARGET

5.9.4. FETCH_DEPENDS

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

5.9.5. EXTRACT_DEPENDS

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

Note:

Use this variable only if the extraction does not already work (the default assumes tar) and cannot be made to work using USES=tar, USES=lha or USES=zip described in Chapter 17, Using USES Macros.

5.9.6. PATCH_DEPENDS

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}: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.

5.9.7. USES

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 17, Using USES Macros.

Warning:

USES cannot be assigned after inclusion of bsd.port.pre.mk.

5.9.8. USE_*

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.

Note:

It is always incorrect to set any USE_* in /etc/make.conf. For instance, setting

USE_GCC=X.Y

(where X.Y is version number) would add a dependency on gccXY for every port, including lang/gccXY itself!

Table 5.8. USE_*
VariableMeans
USE_GCC

The port requires GCC (gcc or g++) to build. Some ports need any GCC version, some require modern, recent versions. It is typically set to any (in this case, GCC from base would be used on versions of FreeBSD that still have it, or lang/gcc port would be installed when default C/C++ compiler is Clang); or yes (means always use stable, modern GCC from lang/gcc port). The exact version can also be specified, with a value such as 4.7. The minimal required version can be specified as 4.6+. The GCC from the base system is used when it satisfies the requested version, otherwise an appropriate compiler is built from the port, and CC and CXX are adjusted accordingly.

Note:

USE_GCC will register a build-time and a run-time dependency.


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.13, “Using KDE” with KDE related variables. Section 6.15, “Using Java” documents Java variables, while Section 6.16, “Web Applications, Apache and PHP” contains information on Apache, PHP and PEAR modules. Python is discussed in Section 6.17, “Using Python”, while Ruby in Section 6.19, “Using Ruby”. Section 6.20, “Using SDL” provides variables used for SDL applications and finally, Section 6.24, “Using Xfce” contains information on Xfce.

5.9.9. Minimal Version of a Dependency

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

p5-Spiffy>=0.26: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.

5.9.10. Notes on Dependencies

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}:graphics/jpeg:extract

will always descend to the jpeg port and extract it.

5.9.11. Circular Dependencies Are Fatal

Important:

Do not introduce any circular dependencies into the ports tree!

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.

5.9.12. Problems Caused by Automatic Dependencies

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.

Example 5.37. Wrong Declaration of an Optional Dependency
.include <bsd.port.pre.mk>

.if exists(${LOCALBASE}/bin/foo)
LIB_DEPENDS=	libbar.so: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.

Example 5.38. Correct Declaration of an Optional Dependency
OPTIONS_DEFINE=	BAR
BAR_DESC=	Calling cellphones via bar

BAR_LIB_DEPENDS=	libbar.so: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.

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.