5.10.依赖

许多应用程序依赖于其他组件。这是大多数类 Unix 操作系统（包括 FreeBSD）非常方便的功能。多个应用程序可以共享通用的依赖项，而不是将每个需要它的软件包或包装都捆绑在一起。有七个变量可以用来确保用户机器上的所有必需部分都存在。此外，还有一些预先支持的依赖变量用于常见情况，以及一些用于控制依赖项行为的额外变量。

5.10.1. LIB_DEPENDS

此变量指定此port依赖的共享库。这是一个包含 lib:dir 个元组的列表，其中 lib 是共享库的名称， dir 是查找共享库的目录，以防找不到。例如，

LIB_DEPENDS=   libjpeg.so:graphics/jpeg

将搜索一个带有任何版本的共享 jpeg 库，并下降到ports树的 graphics/jpeg 子目录以构建和安装它（如果找不到）。

依赖关系检查两次，一次在 build 目标内部，然后在 install 目标内部。此外，依赖项的名称将放入软件包中，因此如果用户系统上没有的话， pkg install (参见 pkg-install(8)) 将自动安装它。

5.10.2. RUN_DEPENDS

此变量指定了运行时此 port 依赖的可执行文件或文件。它是一个列表，其中每个元素是 path:dir [: target ] 元组，其中 path 是可执行文件或文件的名称，dir 是在其中查找它的目录（如果不可用），target 是在该目录中调用的目标。如果路径以斜杠开头（ / ），则将其视为文件，并检查其是否存在于 test -e 中；否则，假定它是可执行文件，并使用 which -s 来确定该程序是否存在于搜索路径中。

例如，

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

如果文件或目录 /usr/local/news/bin/innd 不存在，则从 ports 树的 news/inn 子目录构建并安装它。如果在搜索路径中找不到名为 xmlcatmgr 的可执行文件，则会进入 textproc/xmlcatmgr 进行构建和安装。

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

依赖项从 install 目标内部进行检查。此外，将依赖项的名称放入包中，这样 pkg install (参见 pkg-install(8)) 将在用户系统上自动安装它，如果它尚未安装。如果与 DEPENDS_TARGET 相同，则可以省略目标部分。

一个相当常见的情况是 RUN_DEPENDS 与 BUILD_DEPENDS 完全相同，特别是如果转移的软件是用一种脚本语言编写的，或者如果它需要相同的构建和运行时环境。在这种情况下，直接将一个赋值给另一个既诱人又直观：

RUN_DEPENDS=	${BUILD_DEPENDS}

然而，这种赋值可能会使运行时依赖性中出现未在port的原始 BUILD_DEPENDS 中定义的条目。这是由于 make(1)对变量赋值的惰性评估。考虑一个带有 USE_* 的 Makefile，这些被ports/Mk/bsd.*.mk 处理以增加初始构建依赖项。例如， USES= gmake 将 devel/gmake 添加到 BUILD_DEPENDS 中。为了防止这种额外的依赖关系污染 RUN_DEPENDS ，请创建另一个带有当前 BUILD_DEPENDS 内容的变量，并将其分配给 BUILD_DEPENDS 和 RUN_DEPENDS ：

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

5.10.3. BUILD_DEPENDS

该变量指定此 port 需要构建的可执行文件或文件。与 RUN_DEPENDS 一样，它是一个 path:dir [: target ] 元组的列表。例如，

BUILD_DEPENDS=	unzip:archivers/unzip

将检查一个名为 unzip 的可执行文件，如果未找到，则会进入 ports 树的 archivers/unzip 子目录来构建和安装它。

5.10.4. FETCH_DEPENDS

此变量指定执行文件或文件所需获取的port。就像前两个一样，它是 path:dir 的列表[： target ]元组。例如，

FETCH_DEPENDS=	ncftp2:net/ncftp2

将检查名为 ncftp2 的可执行文件，并进入ports树的 net/ncftp2 子目录以构建和安装它（如果找不到）。

依赖项从 fetch 目标中检查。如果与 DEPENDS_TARGET 相同，则可以省略目标部分。

5.10.5. EXTRACT_DEPENDS

此变量指定此 port 提取所需的可执行文件或文件。与之前一样，它是一个 path:dir [: target ] 元组的列表。例如，

EXTRACT_DEPENDS=	unzip:archivers/unzip

将检查名为 unzip 的可执行文件，并进入 ports 树的 archivers/unzip 子目录进行构建和安装（如果未找到）。

依赖项是从 extract 目标内部检查的。如果与 DEPENDS_TARGET 相同，则可以省略目标部分。

5.10.6. PATCH_DEPENDS

此变量指定此port需要打补丁的可执行文件或文件。与前面类似，这是 path:dir ： target ] 元组的列表。例如，

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

将进入ports树的 java/jfc 子目录以提取它。

依赖项是从 patch 目标内部检查的。如果与 DEPENDS_TARGET 相同，则可以省略目标部分。

5.10.7. USES

可以添加参数来定义 port 使用的不同功能和依赖关系。通过将此行添加到 Makefile 中指定。

USES= feature[:arguments]

要查看所有值的完整列表，请参阅使用 USES 宏。

5.10.8. USE_*

有几个变量存在以定义许多 ports 共享的常见依赖项。它们的使用是可选的，但有助于减少 port Makefiles 的冗长。它们每个都被样式化为 USE_* 。这些变量只能在 port Makefiles 和 ports/Mk/bsd.*.mk 中使用。它们不适用于用户可设置的选项 - 为此请使用 PORT_OPTIONS 。

USE_GCC=X.Y

（其中 X.Y 是版本号）会为每个 port 添加对 gccXY 的依赖，包括 lang/gccXY 本身！

表 8. USE_*

变量	平均数
USE_GCC	'port需要 GCC（ gcc 或 g++ ）来构建。一些ports需要特定的旧版本 GCC，一些需要现代的最新版本。通常设置为 yes （表示始终使用来自ports的稳定、现代 GCC，见 Mk/bsd.default-versions.mk 中的 GCC_DEFAULT ）。这也是默认值。也可以指定确切的版本，例如 10 。当基础系统中的 GCC 满足请求的版本时，使用它，否则从ports构建适当的编译器，并相应调整 CC 和 CXX 。版本说明符后的 :build 参数仅增加了构建时间依赖于port。' '例如:' USE_GCC=yes # port requires a current version of GCC USE_GCC=11:build # port requires GCC 11 at build time only
--	---------------------------------------------------------------------

| For example:

与 gmake 和 configure 相关的变量在 Building Mechanisms 中描述，而 autoconf、automake 和 libtool 在 Using GNU Autotools 中描述。与 Perl 相关的变量在 Using Perl 中描述。X11 变量在 Using X11 中列出。Using Gnome 处理 GNOME 相关的变量，Using KDE 处理 KDE 相关的变量。Using Java 记录了 Java 变量，而 Web Applications 包含有关 Apache、PHP 和 PEAR 模块的信息。Python 在 Using Python 中讨论，而 Ruby 在 Using Ruby 中讨论。Using SDL 提供用于 SDL 应用程序的变量，最后，Using Xfce 包含有关 Xfce 的信息。

5.10.9. 依赖项的最低版本

依赖项的最低版本可以在任何 *_DEPENDS 中指定，除了 LIB_DEPENDS ，使用以下语法：

p5-Spiffy>=0.26:devel/p5-Spiffy

第一个字段包含一个依赖包名称，该名称必须与软件包数据库中的条目匹配，并有一个比较符号和一个软件包版本。如果机器上安装有 p5-Spiffy-0.26 或更新版本，则满足依赖关系。

5.10.10. 依赖注释

如上所述，当需要依赖项时，默认调用的目标是 DEPENDS_TARGET 。它默认为 install 。这是一个用户变量；在port的 Makefile 中从未定义过。如果port需要一种特殊的方式来处理一个依赖关系，使用 *_DEPENDS 的 :target 部分而不是重新定义 DEPENDS_TARGET 。

运行 make clean 时，port 依赖项也会自动清除。如果这不是你想要的，请在环境中定义 NOCLEANDEPENDS 。如果port中的某些内容需要长时间重新构建，请特别考虑这一点，比如 KDE、GNOME 或 Mozilla。

要无条件依赖另一个port，请使用变量 ${NONEXISTENT} 作为 BUILD_DEPENDS 或 RUN_DEPENDS 的第一个字段。只有在需要另一个port的来源时才使用它。通过指定目标也可以节省编译时间。例如

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

将始终下降到 jpeg port 并提取它。

5.10.11. 循环依赖是致命的

ports 构建技术不容忍循环依赖。一旦引入，全世界某处的 FreeBSD 安装几乎立即会出问题，许多其他人很快也会遇到类似情况。这些问题真的很难检测。如果有疑问，在进行更改之前，请确保运行: cd /usr/ports; make index 。这个过程在老旧机器上可能会很慢，但它可能能够避免许多人，包括你自己，在这个过程中遇到大量烦恼。

5.10.12. 自动依赖引起的问题

依赖关系必须通过显式声明或使用 OPTIONS 框架来声明。使用其他方法如自动检测会使索引复杂化，这会给 port 和软件包管理带来问题。

示例 37. 错误声明可选依赖项

.include <bsd.port.pre.mk>

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

尝试自动添加依赖项的问题在于个体port之外的文件和设置随时可能发生变化。例如：建立索引，然后安装一批ports。但其中一个ports安装了被测试的文件。因为安装的port意外地具有一个新的依赖项，所以索引现在是不正确的。即使重新构建索引，如果其他ports也根据其他文件的存在确定它们对依赖项的需求，索引可能仍然是错误的。

示例 38.可选依赖项的正确声明

OPTIONS_DEFINE=	BAR
BAR_DESC=	Calling cellphones via bar

BAR_LIB_DEPENDS=	libbar.so:foo/bar

测试选项变量是正确的方法。只要选项在构建索引之前被定义，它不会引起一批ports的索引不一致。然后可以使用简单脚本来自动构建、安装和更新这些ports及其包。