3.2.1 pkg-descr (关于 port 的冗长描述文件)

　　这是 port 里一个较长的描述文件。 使用一段或几段文件文字来简明的描述这个 ports 是用来做什么的。

　　下面是一个简单的 pkg-descr 例子：

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

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

3.2.2 pkg-plist (port 的装箱单)

　　这份文件列出了 port 所要安装的所有文件。 由于 package 也是据此进行打包， 因此它也被称作 “装箱单(packing list)”. 这个文件中， 路径是相对于安装的路径的 (通常是 /usr/local 或 /usr/X11R6)。 如果您使用 MANn 变量的话， 请不要在这里列出任何联机手册。 假如 port 在安装过程中会创建一些目录， 请务必增加对应的 @dirrm 行， 以便在 package 被卸载时予以自动删除。

　　下面是一个简单的例子：

bin/oneko
lib/X11/app-defaults/Oneko
lib/X11/oneko/cat1.xpm
lib/X11/oneko/cat2.xpm
lib/X11/oneko/mouse.xpm
@dirrm lib/X11/oneko

　　参考 pkg_create(1) 的联机手册以获得更多有关装箱单的细节

　　只有一种情况可以不用 pkg-plist文件。 如果这个 port 只安装很少量的一些文件或目录的话， 这些文件和目录就可以分别列在 Makefile 的 PLIST_FILES和PLIST_DIRS 变量里。 举个例子来说， 我们可以在上面那个 oneko port 里面不用 pkg-plist， 而把下面的这几行加到 Makefile 里面：

PLIST_FILES=    bin/oneko \
                lib/X11/app-defaults/Oneko \
                lib/X11/oneko/cat1.xpm \
                lib/X11/oneko/cat2.xpm \
                lib/X11/oneko/mouse.xpm
PLIST_DIRS=     lib/X11/oneko

　　当然， 如果一个 port 不需要给它自己创建目录的话， 就不用设置 PLIST_DIRS 变量了。

　　不过， 如果用这种方式来列出 port 要安装的文件和目录的话， 也就无法利用在 pkg_create(1) 里介绍的命令来制作 package 了。 因此， 这种方法只适用于那些简单的 port， 使它们更为简化。 同时， 这种做法也有助于减少 ports collection 中的文件数量。 在采用 pkg-plist 之前， 请考虑一下使用这种方法。

　　稍后我们将看到 pkg-plist 以及 PLIST_FILES 如何处理 更复杂的任务。

5.2.1 PORTNAME 和 PORTVERSION

　　您应该把 PORTNAME 设置为您 port 的名字， PORTVERSION 则是 port 的版本号。

5.2.2 PORTREVISION 和 PORTEPOCH

PORTNAME=       gtkmumble
PORTVERSION=    0.10

PORTNAME=       gtkmumble
PORTVERSION=    0.10
PORTREVISION=   1

PORTNAME=       gtkmumble
PORTVERSION=    0.2
PORTEPOCH=      1

PORTNAME=       gtkmumble
PORTVERSION=    0.3
PORTEPOCH=      1

5.2.3 PKGNAMEPREFIX 和 PKGNAMESUFFIX

　　2 个可选的变量， PKGNAMEPREFIX 和 PKGNAMESUFFIX 可以和 PORTNAME 还有 PORTVERSION 配合使用， 形成像这样的 PKGNAME： ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}。 请确定符合我们的 包命名规则。 当然， 不 允许在 PORTVERSION 中使用连字符 (-)。 如果包名有 language- 或 -compiled.specifics 部分 (见下文)， 请分别用 PKGNAMEPREFIX 和 PKGNAMESUFFIX， 不要直接加到 PORTNAME 中。

5.2.4 LATEST_LINK

　　有时， 在 ports 套件中可能会存在同一程序的多个版本。 索引和预编译包的联编系统都需要能够将它们视为不同的软件包， 尽管其 PORTNAME、 PKGNAMEPREFIX， 以及 even PKGNAMESUFFIX 可能是一模一样的。 遇到这种情况时， 就需要将除了 “主” port 之外的其他 port 中的 LATEST_LINK 变量设为不同的值 ── 请参见 editors/vim5 和 editors/vim port， 以及 www/apache* 系列， 以了解它的用法。 需要注意的是， 如何确定 “主” 版本 ── “最流行”、 “受支持最好”， “变动最少”， 等等 ── 已经超过了本书能够给出的建议范围； 这里只是向您介绍在选定了一个 “主” port 之后如何指定其他 port 的版本。

5.2.5 包命名规则

　　以下是您在命名您的包时应当遵守的规则。 这将使得我们放包的目录更利于浏览， 因为我们已经有数以万计的包了， 如果用户觉得查看包名很困难的话， 他们会很快走开的。

　　一个包的名字应该看起来像这样： [language[_region]]-name[[-]compiled.specifics]-version.numbers。

　　要像这样来定义包的名字： ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}。 确保所有的变量符合上面的格式。

1. FreeBSD 会尽力去支持用户当地的语言。 如果这个 port 是某种语言专用的， 那么 language- 部分应该是 由 ISO-639 定义的自然语言的 2 个字母缩写。 比如， ja是表示日本， ru 是表示俄罗斯， vi 表示越南， zh 表示中国， ko 表示韩国， de 表示德国。

   如果是针对某种语言的某一地区的话， 再要加上2个字母的国家代码。 例如， en_US 表示美国英语， fr_CH 表示瑞士法语。

   language- 部分应该在 PKGNAMEPREFIX 变量里设置。

2. name 部分的首字母应该 小写。 (余下的部分可以包含大写字母， 所以当您 要转换一个包含大写字母软件的名字时， 您需要 自己做出判断。) 对于 Perl 5 模块的命名， 有个传统的规则是， 在前面 加上 p5- 并把两个冒号的部分改为连字号， 如： Data::Dumper 模块对应的名字， 就应该是 p5-Data-Dumper。

3. 确认 port 的名字和版本之间有清晰的分隔， 并放入 PORTNAME 和 PORTVERSION 变量。 在 PORTNAME 中包含版本部分的唯一理由是上游软件包真的采用这样的命名方式， 类似 textproc/libxml2 或 japanese/kinput2-freewnn port 这样。 否则， 在 PORTNAME 中就不应包含任何版本信息。 许多 port 采用同样的 PORTNAME 名字是很正常的， www/apache* port 便是如此； 在这种情况下， 不同的版本 (以及不同的索引项) 是由 PKGNAMEPREFIX、 PKGNAMESUFFIX， 以及 LATEST_LINK 的值的不同而有所区别的。

4. 如果 port 可以使用不同的 硬编码默认配置 进行联编 (通常是一系列 port 的一部分目录名)， 则 -compiled.specifics 部分就应该明示编译进去的默认值 (此处连字号是可选的)。 通常的用例包括纸型和不同的字体尺寸。

   -compiled.specifics 部分应该通过 PKGNAMESUFFIX 变量来设置。

5. 版本号应该紧随在连字号 (-) 后面并由数字和字母组成。 特别指出， 另外的连字号是不允许出现在版本号里的。 唯一例外的是字符串 pl (表示 “patchlevel”)， 只能 用在软件没有主版本号和次版本号的情况下。 如果软件的版本号里出现了像 “alpha”， “beta”， “rc”， “pre”， 取第一个字母把它放在小数点的后面。 如果在版本号里一直出现那些名字， 那么在数字和字母之间不应有多余的小数点。

   这个方法是为了更容易得凭版本号来排序 port。 特别注意的是， 确保版本号之间的每部分都由小数点来分隔， 如果日期也是版本号的一部分， 就用这样的格式， yyyy.mm.dd 或者 dd.mm.yyyy 这样的格式， 而非 yy.mm.dd， 因为后者不适合表示千年的格式。

　　这里是一些真实的例子， 我们藉此说明如何把软件作者对软件的命名， 转换为适合我们包的命名方式：

　　如果在原始的代码里没有版本号， 或者原作者并不打算开发另外的版本， 就应把版本号设成 1.0 (就像前面 piewm 的例子那样)。 否则， 要求原始的作者加上版本号或使用日期 (yyyy.mm.dd) 来作为版本号。

5.3.1 CATEGORIES (所属分类)

　　在包制作完成之后， 它会被放在 /usr/ports/packages/All， 并建立一系列来自 /usr/ports/packages 下子目录的符号连接。 这些子目录的名称是由 CATEGORIES 指定的。 这将方便于那些用户在 FTP 站点或 CDROM 的一大堆包里面寻找自己想要的包。 请查看一下 目前的分类表， 并找出一个适合您 port 的分类。

　　此列表也会决定您的 port 在 port 目录中的位置。 如果您在这里设定了 1 个以上的分类， 则认为您 port 文件应放到以第一个分类命名的子目录中。 请参阅 后面 关于如何选择正确分类的更多讨论。

5.3.2 目前的分类表

　　这是目前 port 中的分类。 那些用星号 (*) 标记的是 虚拟分类 ── 它们在ports树里没有相应的子目录， 因而只用来做为次要的分类， 用以方便搜索。

5.3.3 选择正确的分类

　　由于不少分类是重复的， 您通常在用哪个分类作为您 port 的主分类上做出选择。 下面有几条规则能帮您解决这个问题。 这是一个带优先级的表， 按优先级降序罗列：

• 第一个分类必须是个物理的分类 (参阅 前面)。 这对于制作包是必要的。 虚拟分类和物理分类可能在包制作完成后混合在一起。

• 对于特定语言的分类通常放在第一位。 例如， 如果您的 port 会安装一些 X11 的日文字体， 那么 CATEGORIES那行 就应该是 japanese x11-fonts。

• 有特定意义的分类应当被列在无特定意义的前面。 例如， HTML 编辑器应该是这样的 www editors， 而不是其它的什么。 同样地， 您不应该列出 net， 如果 port 属于 irc、 mail、 mbone、 news、 security， 或是 www， 因为 net 可以表示它们的超集。

• 只有当主要的分类是一门自然语言的时候， x11 能被做为第二分类。 需要特别指出的是， 您不应把 X 的应用程序也归类为 x11。

• Emacs 模式应当于相应的应用程序放在同一个分类里， 而不是 editors 分类。 举例来说， 一个用于编辑某种编程语言源代码的 Emacs 模式应该被归为 lang 一类。

• 需要安装可加载内核模块的 port 应在其 CATEGORIES 中归入虚拟分类 kld。

• misc 分类的 port 不能有其它非虚拟的分类。 如果您在您的 CATEGORIES 里设了 misc 和另外的分类， 那意味着可以安全地删除 misc 并把 port 放到其它的子目录中了！

• 如果您的 port 确实不属于现有的分类， 才把它放到 misc。

　　如果您不能确定使用哪个分类， 请在您提交的 send-pr(1) 里加上一行注释， 这样我们就能在导入进 port 树之前讨论一下。 如果您是 committer， 发一份备忘到 FreeBSD ports 邮件列表 先讨论一下。 很多情况是新的 port 被加到错误的分类里， 然后又立即被移走。这会造成源代码库不必要和不良的膨胀。

5.3.4 如何提议建立新的分类

　　由于 Ports Collection 在持续增长， 已经引入了许多新的分类。 新的分类既可以是 虚拟的 分类 ── 这些分类在整个 ports 目录中没有属于自己的子目录 ── 或 物理的 分类 ── 它们有自己的子目录。 接下来我们将讨论与建立新的物理分类有关的事项， 以便帮助您理解如何提议建立新的分类。

　　我们目前的做法是避免建立新的物理分类， 除非有非常多的 port 应被归入这一分类， 或者 port 属于某一特定的小团体 (例如， 与某种人类语言相关)， 或两者皆是。

　　这样做的原因是这类修改会让 committer 和用户都不得不进行 许多工作 来在 Ports Collection 进行或追踪修改。 此外， 提议新的分类通常都会引起争论。 (可能这是因为关于某个分类是否 “太大” 一直没有非常一致的意见的缘故， 另一方面， 分类是否能够能够有助于浏览 (以及多少个分类是合适的)， 等等， 也都是问题。)

　　下面是具体的步骤：

　　提议新的虚拟分类和上述过程类似， 但会容易许多， 因为不需要实际地移动任何 port。 这种情况下， PR 应附带的补丁， 就只需要修改影响到的 port 的 Makefile， 以便在其中的 CATEGORIES 中加入新的分类了。

5.3.5 如何提议对分类进行重新组织

　　有些时候会有一些人提议重新将分类组织为 2-层 或某种基于关键字的结构。 目前为止， 还没有进行任何相关的改变， 因为尽管这些修改比较容易完成， 但修改整个 Ports Collection 所需要进行的工作， 至少也是令人生畏的。 在发表您的观点之前， 请阅读在邮件列表存档中历史上所进行过的提议； 此外， 您也会被要求提供一个可用的原形。

5.4.1 DISTVERSION/DISTNAME (源码包版本号/名称)

　　DISTNAME 是作者称呼您所 port 软件的名字。 DISTNAME 的默认值是 ${PORTNAME}-${PORTVERSION}， 因此只有在需要时才应手工指定。 DISTNAME 只在两个地方用到。 第一处是源码包文件列表 (DISTFILES)， 其默认值是 ${DISTNAME}${EXTRACT_SUFX}。 第二处是源码包应被展开到的目录名， 即 WRKSRC 所指定的目录， 其默认值是 work/${DISTNAME}。

　　某些软件作者发布源码包的时候并不采取 ${PORTNAME}-${PORTVERSION} 这样的模式， 这可以通过设置 DISTVERSION 来自动处理。 PORTVERSION 和 DISTNAME 会自动地展开， 当然， 也可以改掉它。 下表给出了一些例子：

5.4.2 MASTER_SITES (主流下载站点)

　　记录 FTP/HTTP-URL 指向 MASTER_SITES 中原始压缩档的目录部分。 不要忘了结尾的斜线 (/)！

　　make 宏将尝试使用 FETCH 来抓取所指定的源码包文件， 如果无法在本地系统中找到这些文件的话。

　　建议您指定多个镜像站点， 最好是在不同的大洲上的。 这样将有效地防止由于大范围网络问题所导致无法下载的问题。 我们甚至打算增加自动检测距离最近的站点并从那里下载的功能； 使用多个站点是这样做的重要一步。

　　如果原始的源码包可以从比较流行的软件下载站点， 例如 SourceForge、 GNU 或是 Perl CPAN 等等来获得， 您可能会希望使用类似 MASTER_SITE_* 这样的缩写来表示它们 (例如 MASTER_SITE_SOURCEFORGE、 MASTER_SITE_GNU 以及 MASTER_SITE_PERL_CPAN)。 只需将 MASTER_SITES 设为这些变量， 并使用 MASTER_SITE_SUBDIR 来指定路径就可以了。 下面是一个例子：

MASTER_SITES=         ${MASTER_SITE_GNU}
MASTER_SITE_SUBDIR=   make

　　此外， 您还可以用更为简略的格式：

MASTER_SITES=  GNU/make

　　这些变量是在 /usr/ports/Mk/bsd.sites.mk 中定义的。 新项目会随时增加， 因此在您提交 port 之前， 应先看一看这个文件的最新版本。

　　针对常用软件下载站的许多 暗黑魔法 宏， 还能够自动判断目录的结构。 对于这些站点， 只要使用与之对应的缩写， 系统便会自动为您生成相关的子目录配置。

MASTER_SITES=  SF

　　如果系统猜测的路径不对， 则可以使用下面这样的配置来替换。

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

5.4.3 EXTRACT_SUFX (压缩包所用的扩展名)

　　如果您有一个源码包文件， 而它使用了某种怪异的扩展名来表达压缩方法， 应设置 EXTRACT_SUFX。

　　例如， 如果源码包文件的名字是 foo.tgz 而非更为一般的 foo.tar.gz， 您应写上：

DISTNAME=      foo
EXTRACT_SUFX=  .tgz

　　USE_BZIP2 和 USE_ZIP 变量会自动根据需要将 EXTRACT_SUFX 设置为 .tar.bz2 或 .zip。 如果这两个都没设置， 则 EXTRACT_SUFX 的 默认值将是 .tar.gz。

5.4.4 DISTFILES (全部源代码包)

　　有些时候所下载的文件名字和 port 的名字没有任何联系。 例如， 可能是 source.tar.gz， 或者与此类似的其它名字。 也有一些其它的应用软件， 它们的源代码可能被存放到了不同的压缩包中， 而且全都需要下载。

　　如果遇到这种情况， 可以将 DISTFILES 设置为以空格分隔的一组需要下载的文件列表。

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

　　如果没有予以明确的设置， DISTFILES 的默认值将是 ${DISTNAME}${EXTRACT_SUFX}。

5.4.5 EXTRACT_ONLY (只解压缩部分源文件)

　　如果只有一部分 DISTFILES 需要解压缩 ── 例如， 其中的一个是源代码， 而其它则是未压缩的文档 ── 此时应把那些需要解压缩的文件加到 EXTRACT_ONLY 中。

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

　　如果 DISTFILES 中 没有 需要解压缩的文件， 则应将 EXTRACT_ONLY 设为空串。

EXTRACT_ONLY=

5.4.6 PATCHFILES (通过下载得到的补丁文件)

　　如果您的 port 需要来自 FTP 或 HTTP 的一些额外的补丁， 应将 PATCHFILES 设置为这些文件的名字， 并将 PATCH_SITES 指向包含这些文件的目录的 URL (格式与 MASTER_SITES 相同)。

　　如果这些补丁， 由于包含了其它的目录名， 而导致它们不是相对于源代码目录的顶级目录 (也就是 WRKSRC) 的话， 就需要相应地设置 PATCH_DIST_STRIP 了。 例如， 如果补丁中所有的目录名前面都有一个多余的 foozolix-1.0/， 就应设置 PATCH_DIST_STRIP=-p1。

　　不需要担心补丁文件本身是否是压缩的； 如果文件名以 .gz or .Z 结尾， 系统会自动解压缩。

　　如果补丁是同某些其它文件， 例如文档， 一同以 gzip 压缩的 tar 格式发布的， 就不能简单地使用 PATCHFILES 了。 这种情况下， 您应将这些补丁包的文件和位置加入到 DISTFILES 和 MASTER_SITES 中。 然后， 用 EXTRA_PATCHES 变量来指出这些文件， 这样 bsd.port.mk 就会自动地为您应用这些补丁了。 需要特别注意的是， 不要 将补丁文件复制到 PATCHDIR 目录中 ── 这个目录可能是不可写的。

5.4.7 来自不同站点的多个源代码包或补丁文件 (MASTER_SITES:n)

　　(这一节在某种程度上应被视作 “进阶话题”； 刚开始阅读这份文档的读者可能会希望先跳过这一部分)。

　　这一节提供了被称作 MASTER_SITES:n 和 MASTER_SITES_NN 的下载控制机制。 这里我们把它们称为 MASTER_SITES:n。

　　首先给出一些背景。 OpenBSD 在其 DISTFILES 和 PATCHFILES 变量中提供了一个很棒的功能， 即， 允许这些文件和补丁拥有 :n 后缀， 其中 n 可以使用 [0-9]， 来表达组。 例如：

DISTFILES=      alpha:0 beta:1

　　在 OpenBSD 中， 源码包文件 alpha 应被关联到变量 MASTER_SITES0 而不是公共的 MASTER_SITES 变量上； 而 beta 则应关联到 MASTER_SITES1 上。

　　这是一个很有意思的功能， 它可以避免无休止地搜索正确的下载站点的过程。

　　想象 DISTFILES 中指定了 2 个文件， 而 MASTER_SITES 包含了 20 个站点的情形， 这其中许多站点慢如蜗牛， 而 beta 可以在 MASTER_SITES 的所有站点找到， 而 alpha 只能在第 20 个上面找到。 如果监护人了解这一点， 那么检查所有的站点无疑是在浪费时间， 不是吗？ 这显然不是开始一个愉快周末的好办法！

　　现在您有了一个感性的认识了， 想象一下 DISTFILES 和更多的 MASTER_SITES。 显然， 我们的 “distfiles 调查员先生” 会感谢您减少他浪费在等待下载上所耗费的时间。

　　下一节中， 将按照 FreeBSD 对上述想法的实现来加以阐释。 我们对 OpenBSD 所提出的概念进行了一些改进。

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

5.4.8 DIST_SUBDIR (独立的源码包子目录)

　　避免让您的 port 使 /usr/ports/distfiles 陷入混乱。 如果您的 port 需要下载很多文件， 或者需要下载可能与其它 port 的源文件名冲突的文件 (例如， Makefile)， 则应将 DIST_SUBDIR 设置为 port 的名字 (通常可以用 ${PORTNAME} 或 ${PKGNAMEPREFIX}${PORTNAME})。 这将把 DISTDIR 从默认的 /usr/ports/distfiles 改为 /usr/ports/distfiles/DIST_SUBDIR， 并将与您的 port 有关的文件放到那个目录中。

　　此外， 它也会在备份文件主服务器 ftp.FreeBSD.org 上查找同一子目录下的文件 (直接在您的 Makefile 中设置 DISTDIR 则不会有这样的效果， 因此您应使用 DIST_SUBDIR。)

5.4.9 ALWAYS_KEEP_DISTFILES (一直保存源码包)

　　如果您的 port 采用的是预编译的包， 但却采用了某种要求源代码必须与预编译版本一同提供的授权， 例如 GPL， 则应使用 ALWAYS_KEEP_DISTFILES 来告诉 FreeBSD 联编集群保留一份在 DISTFILES 中文件的副本。 一般来说这些 port 的用户并不需要这些文件， 因此， 只在定义了 PACKAGE_BUILDING 符的时候， 才将源代码包文件加入 DISTFILES 是个好主意。

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

　　当您在 DISTFILES 加入其它文件时， 请务必确保这些文件也出现在了 distinfo 中。 此外， 这些额外的文件通常也会展开到 WRKDIR 中， 对于某些 ports， 这可能导致一些不希望的副作用， 因而需要进行特别的处理。

5.7.1 LIB_DEPENDS (依赖的函数库/共享库)

　　这个变量用于指定 port 所依赖的共享库。 其内容是由一系列 lib:dir[:target] 元组构成的表， 其中 lib 是共享库的名字， 而 dir 则是在找不到时应该从哪里联编和安装， 最后， target 用于指定在那个目录中调用的 target。 例如，

LIB_DEPENDS=   jpeg.9:${PORTSDIR}/graphics/jpeg

　　依赖关系会被检测两次， 一次是在 extract target 中， 而另一次则是在 install target。 另外， 依赖关系的名字会放到 package 中， 以便让 pkg_add(1) 能够自动地在用户系统上安装所需的未安装的其它 package。

5.7.2 RUN_DEPENDS (依赖的运行环境)

　　这个变量可以用来指定 port 在运行时所需要的可执行文件， 以及资源文件。 它是一系列 path:dir[:target] 元组的列表， 这里， path 时所需的可执行， 或者资源文件的名字， dir 是在无法找到这些文件或目录时， 去什么地方完成联编和安装以便获得这些文件； 而 target 则用来指定在这个目录中所调用的 target 的名字。 假如 path 以斜线 (/) 开始， 则会当作普通文件， 使用 test -e 来测试； 反之， 则系统会假定这是一个可执行文件， 并且用 which -s 来检测程序是否存在于搜索路径中。

　　例如，

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

　　将检查文件， 或者目录 /usr/local/etc/innd 是否存在， 如果找不到， 则将从 port 目录的 news/inn 子目录加以安装。 系统也会检查是否能够在搜索路径中找到名为 xmlcatmgr 的文件， 如果找不到的话， 则会进入 ports 目录中的 textproc/xmlcatmgr 子目录， 并进行联编和安装的操作。

　　这个依赖关系会在 install target 的过程中进行检查。 此外， 依赖关系的名字会被放到 package 中， 以便 pkg_add(1) 能够在用户的系统中尚未安装相关软件时自动地安装那些 package。 如果您希望指定一个的 target 和默认的 DEPENDS_TARGET 相同， 则可以略去不写。

　　一种比较常见的情形是 RUN_DEPENDS 和 BUILD_DEPENDS 完全一样， 这种情况在移植的软件是采用脚本语言书写， 或联编环境与运行环境需求相同时尤其普遍。 这种情况可以用下面简单明了的方式直接将其中一个变量赋值给另一个变量：

RUN_DEPENDS= ${BUILD_DEPENDS}

　　不过， 这种赋值有可能会令运行环境被某些没有在 port 原本的 BUILD_DEPENDS 明确定义的依赖关系污染。 导致这种情况的原因是 make(1) 计算变量赋值时默认采用的是延后计算 (lazy evaluation)。 例如， 如果在 Makefile 中使用了 USE_* 变量， 这些变量就会由 ports/Mk/bsd.*.mk 处理， 并填写与之对应的联编依赖关系。 例如， USE_GMAKE=yes 会把 devel/gmake 加入到 BUILD_DEPENDS。 如果希望避免这些附加的依赖关系污染 RUN_DEPENDS， 在使用赋值的时候就需要小心考虑这类扩展的情况， 例如， 可以在赋值展开之前复制变量的值：

RUN_DEPENDS:=  ${BUILD_DEPENDS}

5.7.3 BUILD_DEPENDS (依赖的联编环境)

　　此变量用于指定用来联编 port 的可执行文件或资源文件。 与 RUN_DEPENDS 类似， 它是一个 path:dir[:target] 元组的列表。 例如，

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

5.7.4 FETCH_DEPENDS (依赖的下载环境)

　　这一变量用于指定 port 在下载时所需的可执行文件或资源文件。 和前两个类似， 它是一组 path:dir[:target] 元组。 例如，

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

　　这个依赖关系是在 fetch target 过程中检查的。 如果与 DEPENDS_TARGET 相同， 则可以省略 target 部分。

5.7.5 EXTRACT_DEPENDS (依赖的解压缩环境)

　　此变量用于指定 port 在解压缩时所需的可执行文件或其它资源文件。 和前一个变量类似， 它是一系列 path:dir[:target] 元组的列表。 例如，

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

　　这个依赖关系是在 extract target 的过程中检查的。 如果与 DEPENDS_TARGET 相同， 则可以略去 target 部分。

5.7.6 PATCH_DEPENDS (依赖的打补丁环境)

　　这个变量用于指定 port 在进行 patch 操作时所需的可执行文件或其它资源文件。 和前一个变量类似， 它是一组 path:dir[:target] 元组的表。 例如，

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

　　这个依赖关系是在 patch target 的过程中检查的。 target 部分如果和 DEPENDS_TARGET 相同， 就可略去不写。

5.7.7 USE_*

　　提供了一系列变量， 用以封装大量 port 都用到的依赖关系。 虽然使用这些变量是可选的， 但它们能显著减少 port 的 Makefile 复杂性。 这些变量的共同特征在于， 它们的名字都是 USE_* 这样的形式。 这些变量的使用， 应严格限制于 port 的 Makefile 以及 ports/Mk/bsd.*.mk， 而绝不应用于表达用户能够设置的选项 ── 这种情况下应采用 WITH_* 和 WITHOUT_* 这样的变量。

　　与 gmake 和 configure 脚本有关的变量在 第 6.3 节 中进行了介绍， 而 autoconf、 automake 以及 libtool 的介绍则可以在 第 6.4 节 找到。 第 6.6 节 介绍了与 Perl 有关的的变量。 第 6.7 节 中列出了关于 X11 的变量。 关于 GNOME 的变量在 第 6.8 节， 而关于 KDE 的则在 第 6.10 节。 第 6.11 节 讲述了和 Java 有关的变量， 而 第 6.12 节 则包含了关于 Apache、 PHP 以及 PEAR 的介绍性信息。 关于 Python， 在 第 6.13 节 进行了讨论， 而关于 Ruby 的介绍， 则可以在 第 6.16 节 中找到。 第 6.17 节 提供了用于 SDL 应用程序的变量介绍， 最后， 第 6.20 节 包含了关于 Xfce 的信息。

5.7.8 在依赖关系中指定最低版本

　　在依赖某个其他 port 时， 可以采用下面的句法， 通过除 LIB_DEPENDS 之外的 *_DEPENDS 变量来指定最低版本：

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

　　第一个字段指明了所依赖 package 的名字， 用以与 package 数据库中的某项匹配， 然后是比较算符， 以及 package 的版本号。 前面的例子中， 如果系统中安装了 p5-Spiffy-0.26 则认为满足了依赖条件。

5.7.9 关于依赖关系的补充说明

　　如前面所提到的那样， 在需要某一依赖的 port 时， 将调用 DEPENDS_TARGET 所指定的 target。 这一变量的默认值是 install。 这不是一个用户变量， 它不应在 port 的 Makefile 中予以定义。 如果您的 port 需要使用特殊的 target 来处理依赖关系， 应使用 *_DEPENDS 的 :target 部分， 而不是重定义 DEPENDS_TARGET 来完成。

　　当您输入 make clean 时， 其依赖的 port 也会自动进行清理。 如果您不希望如此， 应定义环境变量 NOCLEANDEPENDS。 如果 port 依赖一些重新联编需要花费很长时间的 port 时， 例如 KDE， GNOME 或 Mozilla 时， 这一方法会非常有用。

　　要无条件地依赖某个 port， 可以使用 ${NONEXISTENT} 作为 BUILD_DEPENDS 或 RUN_DEPENDS 的第一部分。 只有在您需要使用其它 port 提供的源代码时才应这样做。 通常也可以通过这样指定来缩短编译所需的时间。 例如

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

5.7.10 循环的依赖关系是致命的

　　ports 联编技术不能够容忍循环依赖关系。 如果您引入了这样的关系， 就一定会有人安装的 FreeBSD 会因此而损坏， 而且这种现象会越来越多。 这些情形很难检测； 如果有疑虑， 在进行这样的修改之前， 务必执行： cd /usr/ports; make index。 这个过程在旧的机器上会很慢， 但能够让大量的用户 ── 也包括您自己 ── 拯救于由这种问题所造成的困惑之中。

5.11.1 开关 (Knobs)

5.11.2 OPTIONS (菜单式可选项)

OPTIONS=   OPTION  "说明性文字" 默认值 ...

OPTIONS=      FOO "启用 foo 选项" On \
              BAR "支持 bar 功能" Off

.include <bsd.port.options.mk>

.if defined(WITHOUT_FOO)
CONFIGURE_ARGS+=    --without-foo
.else
CONFIGURE_ARGS+=    --with-foo
.endif

.if defined(WITH_BAR)
RUN_DEPENDS+=   bar:${PORTSDIR}/bar/bar
.endif

.include <bsd.port.mk>

OPTIONS=      FOO "Enable option foo" On

.include <bsd.port.pre.mk>

.if defined(WITHOUT_FOO)
CONFIGURE_ARGS+=    --without-foo
.else
CONFIGURE_ARGS+=    --with-foo
.endif

.include <bsd.port.post.mk>

5.11.3 自动激活的特性

　　在使用 GNU configure 脚本时， 一定要小心有些特性会由其自动检测而激活。 您应通过明确地指定相应的 --without-xxx 或 --disable-xxx 参数到 CONFIGURE_ARGS 来禁用不希望的特性。

.if defined(WITH_FOO)
LIB_DEPENDS+=       foo.0:${PORTSDIR}/devel/foo
CONFIGURE_ARGS+=    --enable-foo
.endif

　　在前面的例子中， 假设系统中已经安装了 libfoo 库。 用户可能并不希望应用程序使用 libfoo， 因此他在 make config 对话框中关掉了这个选项。 但是， 应用程序的 configure 脚本检测到了系统中存在这个库， 并将其加入到了最终可执行文件支持的功能中。 现在， 如果用户决定从系统中卸载 libfoo 时， ports 系统就无法保护这个应用程序免遭破坏了 (因为没有记录 libfoo 的依赖关系)。

.if defined(WITH_FOO)
LIB_DEPENDS+=       foo.0:${PORTSDIR}/devel/foo
CONFIGURE_ARGS+=    --enable-foo
.else
CONFIGURE_ARGS+=    --disable-foo
.endif

　　在第二个例子中， libfoo 库被明确禁用。 即使系统中已经安装了这个库， configure 脚本也不会启用相应的功能了。

5.12.1 WRKSRC (开始联编操作的目录名)

　　这个变量给出了在应用程序的源代码包解压缩之后所生成的目录的名字。 如果我们之前的例子解压缩生成一个叫做 foo (而不是 foo-1.0) 的目录， 您应：

WRKSRC=      ${WRKDIR}/foo

　　或者， 也可能是

WRKSRC=      ${WRKDIR}/${PORTNAME}

5.12.2 NO_WRKSUBDIR (不需要临时的联编目录)

　　如果 port 完全不需要写入到某个子目录中， 您应设置 NO_WRKSUBDIR 以明示这一点。

NO_WRKSUBDIR= yes

5.13.1 CONFLICTS_INSTALL

　　如果您的软件包不能与某些软件包同时安装 (例如由于安装同样的文件到相同的位置、 运行时不兼容等等)， 则应把其它软件包的名字列在 CONFLICTS_INSTALL 变量中。 此处可以使用 shell 通配符， 如 * 和 ?。 列出其它软件包的名字时需要遵循它们在 /var/db/pkg 中出现的样子。 请确保 CONFLICTS_INSTALL 不会匹配到您正制作的这个预编译包的名字， 否则， 使用 FORCE_PKG_REGISTER 来强制安装就没有办法进行了。 对于 CONFLICTS_INSTALL 的检查是在联编过程之后、 安装开始之前进行的。

5.13.2 CONFLICTS_BUILD

　　如果您的软件包在系统中存在某些其它软件包时不能完成联编， 则应把其它软件包的名字列在 CONFLICTS_BUILD 变量中。 此处可以使用 shell 通配符， 如 * 和 ?。 列出其它软件包的名字时需要遵循它们在 /var/db/pkg 中出现的样子。 对于 CONFLICTS_BUILD 的检查是在联编过程开始之前进行的。 联编时的冲突不会在编译好的包中予以记录。

5.13.3 CONFLICTS

　　如果您的 port 在某些其它 port 已经存在的情况下既不能联编， 也不能安装， 则应把其它软件包的名字列在 CONFLICTS 变量中。 此处可以使用 shell 通配符， 如 * 和 ?。 列出其它软件包的名字时需要遵循它们在 /var/db/pkg 中出现的样子。 请确保 CONFLICTS 不会匹配到您正制作的这个预编译包的名字， 否则， 使用 FORCE_PKG_REGISTER 来强制安装就没有办法进行了。 对于 CONFLICTS 的检查是在联编过程之后、 安装开始之前进行的。

5.14.1 INSTALL_* 宏

　　一定要使用由 bsd.port.mk 提供的宏， 以确保在您自己的 *-install target 中能够以正确的属主和权限模式安装文件。

• INSTALL_PROGRAM 是安装可执行二进制文件的命令。

• INSTALL_SCRIPT 是安装可执行脚本文件的命令。

• INSTALL_LIB 是安装动态连接库的命令。

• INSTALL_KLD 是用于安装可加载式内核模块的命令。 在某些平台上， 当对内核模块进行 strip 之后会导致一些问题， 因此您应使用这个宏而不是 INSTALL_PROGRAM 来安装内核模块。

• INSTALL_DATA 是安装可共享数据的命令。

• INSTALL_MAN 是安装联机手册和其他文档的命令 (注意它并不会执行压缩操作)。

　　这些宏展开后基本上都是包含适当参数的 install 命令。

5.14.2 对可执行文件和动态连接库做脱模 (strip) 操作

　　除非不得不进行， 否则不要手工对可执行文件作脱模操作。 所有文件在安装时都应脱模， 但 INSTALL_PROGRAM 宏会在安装的同时对其进行脱模 (参见下一节的内容)。 INSTALL_LIB 宏

　　如果您需要对某一文件进行脱模， 但不希望使用 INSTALL_PROGRAM 及 INSTALL_LIB 宏， 则应使用 ${STRIP_CMD} 来处理程序。 一般而言这应该在 post-install target 中进行。 例如：

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

　　可以使用 file(1) 命令来检查所安装的可执行文件是否进行过脱模。 如果它没有给出 not stripped 的提示， 则表示已经做过脱模了。 另外， strip(1) 不会对已经脱模过的文件重新脱模， 它会直接退出的。

5.14.3 安装一个目录下的全部文件

　　有时， 会有需要安装大量的文件， 并保持其层次结构， 例如， 将整个目录结构从 WRKSRC 复制到 PREFIX 的目标目录。

　　针对这种情况， 系统提供了两个宏。 使用这些宏， 而不是直接使用 cp 的优势是它们能够确保目标文件的属主和权限正确。 第一个宏， COPYTREE_BIN 将所有安装的文件视为可执行文件， 因而适合安装文件到 PREFIX/bin。 第二个宏， COPYTREE_SHARE， 则不会设置可执行权限， 因此适合于将文件安装到 PREFIX/share 下。

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

　　这个例子将原作者提供的整个 examples 目录复制到您 port 指定的安装示范文件的位置。

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

　　这个例子将把夏季的三个月的数据， 复制到 DATADIR 中的 summer 子目录。

　　经由设置 COPYTREE_* 宏的第三个参数， 您还可以为 find 指定额外的参数。 例如， 如果希望安装除了 Makefile 之外的其他所有文件， 可以使用下述命令。

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

　　需要注意的是， 这些宏并不能自动将所安装的文件加到 pkg-plist 中， 您还是需要自行列出它们。

5.14.4 安装附加的文档

　　如果您的软件包含了标准的联机手册和 info 手册以外的文档， 而且您认为它们对用户会有用， 请把这些文档安装到 PREFIX/share/doc 下。 和前面类似， 这也可以在 post-install target 中完成。

　　为您的 port 建立一个新的目录。 这个目录的名字应该反映它是属于哪个 port 的。 通常建议使用 PORTNAME。 不过， 如果您认为不同版本的 port 可能会同时安装， 也可以用完整的 PKGNAME。

　　另外， 应该让是否安装取决于变量 NOPORTDOCS 的设置， 这样用户就能够在 /etc/make.conf 中禁止安装它。 例如：

post-install:
.if !defined(NOPORTDOCS)
    ${MKDIR} ${DOCSDIR}
    ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${DOCSDIR}
.endif

　　这里是一些便于使用的变量， 以及它们在 Makefile 中默认的展开方式：

• DATADIR 会展开成 PREFIX/share/PORTNAME。

• DATADIR_REL 会展开成 share/PORTNAME。

• DOCSDIR 会展开成 PREFIX/share/doc/PORTNAME。

• DOCSDIR_REL 会展开成 share/doc/PORTNAME。

• EXAMPLESDIR 会展开成 PREFIX/share/examples/PORTNAME。

• EXAMPLESDIR_REL 会展开成 share/examples/PORTNAME。

　　这些变量也会被导出到 PLIST_SUB 中。 只要可能， 它们的值就将在那里以相对于 PREFIX 的路径形式出现。 也就是说， share/doc/PORTNAME 在装箱单中默认情况下会替换掉 %%DOCSDIR%%， 等等。 (更多的 pkg-plist 代换可以在 这里 找到。)

　　所有非无条件安装的文档文件和目录， 都应在 pkg-plist 出现， 并且使用 %%PORTDOCS%% 前缀， 例如：

%%PORTDOCS%%%%DOCSDIR%%/AUTHORS
%%PORTDOCS%%%%DOCSDIR%%/CONTACT
%%PORTDOCS%%@dirrm %%DOCSDIR%%

　　如果不希望在 pkg-plist 中逐个列举文档文件， port 也可以将 PORTDOCS 设置为一组文件及其 shell glob 模式， 通过这种方式来加入到最终的装箱单中。 这些名字应是相对于 DOCSDIR 的。 因此， 使用了 PORTDOCS， 并将文档安装到非标准位置的 port， 应相应地设置 DOCSDIR。 如果有在 PORTDOCS 中列出目录， 或者这一变量中的 glob 模式匹配到了目录， 则整个子树中的文件和目录， 都将被注册到最终的装箱单中。 如果定义了 NOPORTDOCS， 则 PORTDOCS 中定义的文件和目录将不被安装或加入装箱单。 是否安装文档到前面所说的 PORTDOCS 仍取决于 port 本身。 下面是一个典型的使用 PORTDOCS 的例子：

PORTDOCS=       README.* ChangeLog docs/*

5.14.5 子目录

　　尽可能让 port 将它创建的文件， 放置到 PREFIX 中正确的位置。 一些 port 会把各式各样的东西混在一起， 并放到一个同名的目录中， 这是不对的。 另外， 许多 port 会把除了可执行文件、 头文件和联机手册之外的所有文件， 全都一股脑地放到 lib 中， 这在和 BSD 配合使用时会有问题。 多数文件， 应被放到下列位置之一： etc (安装/配置文件)、 libexec (由系统内部调用的可执行文件)、 sbin (为超级用户/管理员提供的可执行文件)、 info (用于 info 浏览器的文档) 或 share (平台无关的其它文件)。 请参见 hier(7) 以了解进一步的详情； 针对 /usr 的那些规则， 同样也适用于 /usr/local。 例外情况是那些需要和 USENET “news” 打交道的 port， 它们可以选择采用 PREFIX/news 作为文件的目的地。

6.2.1 NO_PACKAGE (禁止编译结果打包)

　　这个变量表示我们可能不能生成这个应用 程序的二进制文件。例如，他的协议不允许 二进制文件的再次发行，或者他可能禁止从 补丁过的源代码打包的发行。

　　不管怎么样，port的 DISTFILES 可以 随意的镜像到FTP/HTTP。除非NO_CDROM 变量也被设置，软件包也可以发行在一张CD-ROM （或类似的媒介上）。

　　NO_PACKAGE也能用在当二进制包 不是非常有用，并且这个应用软件经常要 从源代码编译。例如：当这个应用软件在 编译的时候要在配置信息中指定特定的硬件 代码时，可以设置NO_PACKAGE。

　　NO_PACKAGE应该设置成字符串 来描述为什么这个软件 不能打包。

6.2.2 NO_CDROM (禁止以 CDROM 发行预编译包)

　　这个变量仅仅指出虽然我们允许 生成二进制包，但也许我们既不能把这个 软件包也不能把port的DISTFILES 放在光盘（或类似的媒介）上销售。但不管怎么样， 二进制包和port的DISTFILES 可以从FTP/HTTP上获得。

　　如果这个变量和 NO_PACKAGE一起被设置， 那么这个port的DISTFIELS 将只能从FTP/HTTP上获得。

　　NO_CDROM 应该被设置成一个字符串 来描述为什么这个port不能重新发布在CD-ROM上。 例如：如果这个port的协议仅仅是用于“非商业活动” ,那么这个变量就能设置了。

6.2.3 NOFETCHFILES (不自动抓取指定的文件)

　　在 NOFETCHFILES 变量中定义的文件， 不会自动从 MASTER_SITES 抓取。 一种典型的用例是， 使用来自某个软件供应商提供的 CD-ROM 上的文件。

　　用于检查在 MASTER_SITES 上是否包含了所需文件的工具， 应忽略这些文件， 而不是报告它们不存在。

6.2.4 RESTRICTED (禁止任何形式的再分发)

　　如果应用程序既不允许镜像其 DISTFILES， 也不允许发布其预编译版本的包， 设置它就可以了。

　　NO_CDROM 或 NO_PACKAGE 不应与 RESTRICTED 同时设置， 因为它包含了这些情形。

　　RESTRICTED 应设置为一个说明 port 为何不能发布的串。 典型情况可能是由于 port 包含了专有的软件， 因而用户需要自行下载 DISTFILES， 可能是注册或者同意某一 EULA 的条款。

6.2.5 RESTRICTED_FILES (禁止某些文件的再分发)

　　当设置了 RESTRICTED 或 NO_CDROM 时， 这个变量会默认设置为 ${DISTFILES} ${PATCHFILES}， 否则它会为空。 如果只有某些源码包文件是受限的， 则可以用这个变量来指明它们。

　　注意， port committer 应该在 /usr/ports/LEGAL 中为每一个源码包文件撰写对应的项目， 并介绍这些限制的原因。

6.3.1 Ports 的并行联编

　　FreeBSD ports 框架支持使用多个 make 子进程来进行并行编译， 在 SMP 上这可以全面地利用系统的 CPU 计算能力， 令 port 的联编过程更快、 更有效率。

　　目前这是通过向原作者的代码传递 make(1) 参数 -jX 来实现的。 遗憾的是， 并不是所有的 port 都能够很好地处理这个选项。 因此， 必须通过明确地在 Makefile 中指定 MAKE_JOBS_SAFE=yes 来启用这一功能。

　　从 port 监护人的角度还有一个控制的方法是设置 MAKE_JOBS_UNSAFE=yes 变量。 这个变量主要是用于已知不能与 -jX 配合使用的 port， 即使用户在 /etc/make.conf 中定义了 FORCE_MAKE_JOBS=yes 变量， 系统也不会使用并行编译。

6.3.2 make、 gmake， 以及 imake

　　如果 port 用到了 GNU make， 应设置 USE_GMAKE=yes。

　　对于 X 应用程序的 port， 如果它使用 imake 根据 Imakefile 文件来生成 Makefile， 则应设置 USE_IMAKE=yes。 这会使联编过程中的配置 (configure) 阶段自动执行 xmkmf -a。 如果 -a 标志会给您的 port 带来麻烦， 则需设置 XMKMF=xmkmf。 如果 port 用到了 imake 但并不使用 install.man target， 则应设置 NO_INSTALL_MANPAGES=yes。

　　如果 port 源文件的 Makefile 的主联编 target 是 all 以外的名字， 应对应地设置 ALL_TARGET。 对于 install 而言， 对应的变量是 INSTALL_TARGET。

6.3.3 configure 脚本

　　假如 port 使用 configure 脚本来从 Makefile.in 生成 Makefile 文件， 需要设置 GNU_CONFIGURE=yes。 如果希望传额外的参数给 configure 脚本 (默认参数为 --prefix=${PREFIX} --infodir=${PREFIX}/${INFO_PATH} --mandir=${MANPREFIX}/man --build=${CONFIGURE_TARGET})， 应通过 CONFIGURE_ARGS 来指定这些参数。 类似地， 可以通过 CONFIGURE_ENV 变量来传递一些环境变量。

　　如果您的软件包使用 GNU configure， 而生成的可执行文件命名方式 “怪异” 如 i386-portbld-freebsd4.7-应用程序名， 则需要更进一步地通过改变 CONFIGURE_TARGET 变量来按照较新版本的 autoconf 生成的脚本所希望的方式指定 target。 其方法是， 紧随 Makefile 中 GNU_CONFIGURE=yes 一行之后加入：

　　 CONFIGURE_TARGET=--build=${MACHINE_ARCH}-portbld-freebsd${OSREL}

6.3.4 使用 scons

　　如果您的 port 使用 SCons， 就需要定义 USE_SCONS=yes 了。

　　如果希望让第三方的 SConstruct 尊重通过 SCONS_ENV (其中最重要的是 CC/CXX/CFLAGS/CXXFLAGS 配置) 传给 Scons 的配置， 则需要对 SConstruct 进行修改， 使联编的 Environment 按下列方式建立：

env = Environment(**ARGUMENTS)

　　其后， 可以通过 env.Append 和 env.Replace 来对它进行修改。

6.4.1 入门

　　众多 GNU autotools 提供了一种在多重操作系统和机器架构之上联编软件的抽象机制。 在 Ports Collection 中， port 可以通过简单的方法来使用这些工具：

USE_AUTOTOOLS= 工具:版本[:操作] ...

　　撰写本书时， 工具 可以设置为 libtool、 libltdl、 autoconf、 autoheader、 automake 或 aclocal 之一。

　　版本 用来指定希望使用的工具的特定版本 (参见 devel/{automake,autoconf,libtool}[0-9]+ 以了解有效的版本号)。

　　操作 是一个可选的扩展选项， 用于修改如何使用工具。

　　可以同时指定多个不同的工具， 可以在一行中指定， 也可以用 Makefile 的 += 结构。

　　最后， 可以使用一个特殊的名为 autotools 的工具， 它会安装全部可用的 autotools 版本， 以适应跨平台开发的需要。 您可以通过安装 devel/autotools port 来达到这一目的。

6.4.2 libtool

　　使用 GNU 联编框架的共享库通常会使用 libtool 来调整共享库的编译和安装， 以便与所运行的操作系统相匹配。 通常的做法是使用应用程序所附带的 libtool 副本。 如果需要使用外部的 libtool， 则可以使用 Ports 套件提供的版本：

USE_AUTOTOOLS= libtool:版本[:env]

　　如果不使用额外的操作符， libtool:版本 表示希望联编框架使用 configure 脚本来对系统所安装的 libtool 进行修补。 这会暗含地定义 GNU_CONFIGURE。 更进一步， 联编框架还会设置一系列 make 和 shell 变量用于 port 后续的操作。 请参见 bsd.autotools.mk 了解进一步的详情。

　　如果指定了 :env 操作符， 则表示只设置环境， 而跳过其他的操作。

　　最后， LIBTOOLFLAGS 和 LIBTOOLFILES 可以用来替换最常修改的参数， 以及将被 libtool 修补的文件。 多数 port 不需要这样做。 请参见 bsd.autotools.mk 以了解进一步的细节。

6.4.3 libltdl

　　一些 ports 会使用 libltdl 库， 后者是 libtool 软件包的一部分。 使用这个库并不意味着必须使用 libtool 本身， 因此提供了另一组结构。

USE_AUTOTOOLS= libltdl:版本

　　目前， 这一设置所做的全部工作是将 LIB_DEPENDS 设置为适当的 libltdl port， 并作为一项方便的功能， 协助开发人员消除在 USE_AUTOTOOLS 框架以外的， 对于 autotools port 的依赖。 这个工具并不提供其它的操作符。

6.4.4 autoconf 和 autoheader

　　某些 port 并没有直接提供 configure 脚本， 但包含了作为 autoconf 模板的 configure.ac 文件。 可以用下列设置来要求 autoconf 创建 configure 脚本， 并使用 autoheader 来为 configure 脚本创建模板头文件。

USE_AUTOTOOLS= autoconf:版本[:env]

　　以及

USE_AUTOTOOLS= autoheader:版本

　　上述设置会暗含使用 autoconf:版本。

　　对于 libtool， 设置与前面类似。 如果指定可选的 :env 操作符， 则表示只设置用于后续工作的环境。 如果不指定， 则会对 port 进行相应的修补和重新配置。

　　其它的可选变量， 如 AUTOCONF_ARGS 和 AUTOHEADER_ARGS 可以通过 port 的 Makefile 来显式地指定替换。 类似 libtool， 多数 port 并不需要这样做。

6.4.5 automake 和 aclocal

　　某些软件包只提供了 Makefile.am 文件。 这些文件必须首先用 automake 转换为 Makefile.in 并使用 configure 来生成实际的 Makefile。

　　类似地， 偶尔会有一些软件包不提供联编所需的 aclocal.m4 文件。 这些文件可以通过使用 aclocal 来扫描 configure.ac 或 configure.in 自动生成。

　　aclocal 与 automake 有和 autoheader 与 autoconf 在前面一节中所介绍的相类似的关系。 aclocal 会暗含使用 automake， 因此：

USE_AUTOTOOLS= automake:版本[:env]

　　和

USE_AUTOTOOLS= aclocal:版本

　　也自动暗含使用 automake:版本。

　　与 libtool 类似， autoconf 如果使用了可选的 :env 操作符表示仅仅设置用于后续使用的环境， 如果不设置， 则会对 port 进行重新配置。

　　对于 autoconf 和 autoheader 而言， automake 和 aclocal 提供了对应的可选参数变量 AUTOMAKE_ARGS 和 ACLOCAL_ARGS， 如果需要的话， 可以在 port 的 Makefile 中指定。

6.5.1 基本用法

　　如果您的 port 需要使用 gettext， 只要将 USE_GETTEXT 设置为 yes， 您的 port 就会增加对 devel/gettext 的依赖。 USE_GETTEXT 也可以指定为所需的 libintl 库的版本， 它是 gettext 的基本组成部分， 尽管如此， 强烈建议您不要 使用这个功能： 您的 port 应能与目前版本的 devel/gettext 配合工作。

　　在 port 中相当常见的情况下， 会需要同时使用 gettext 和 configure。 一般而言， GNU configure 能够自动定位到 gettext。 如果它没有成功地完成这项工作， 则可以通过类似下面这样的 CPPFLAGS 和 LDFLAGS 将 gettext 的位置告诉它：

USE_GETTEXT=    yes
CPPFLAGS+=      -I${LOCALBASE}/include
LDFLAGS+=       -L${LOCALBASE}/lib

GNU_CONFIGURE=  yes
CONFIGURE_ENV=  CPPFLAGS="${CPPFLAGS}" \
                LDFLAGS="${LDFLAGS}"

　　当然， 不需要传参数给 configure 时， 代码可以更为简练：

USE_GETTEXT=    yes
GNU_CONFIGURE=  yes
CONFIGURE_ENV=  CPPFLAGS="-I${LOCALBASE}/include" \
                LDFLAGS="-L${LOCALBASE}/lib"

6.5.2 可选用法

　　一些软件产品提供了禁用 NLS 的能力， 例如， 在 configure 时， 指定 --disable-nls 参数。 如果您 port 的软件支持这种配置， 则应根据 WITHOUT_NLS 的设置来有条件地使用 gettext。 对于比较简单和不太复杂的 port， 您可以使用下列结构：

GNU_CONFIGURE=          yes

.if !defined(WITHOUT_NLS)
USE_GETTEXT=            yes
PLIST_SUB+=             NLS=""
.else
CONFIGURE_ARGS+=        --disable-nls
PLIST_SUB+=             NLS="@comment "
.endif

　　您要做的下一件事是合理地安排装箱单文件， 使其根据用户配置来决定是否将消息编录 (message catalog) 文件放入最终的装箱单。 前面已经介绍了在 Makefile 中所需的写法， 这种做法在 高级 pkg-plist 用法 这节中进行了介绍。 简单地说， 在 pkg-plist 中出现的 %%NLS%% 均会在禁用 NLS 时自动替换为 “@comment ”， 反之则替换为空串。 这样， 在最终的装箱单中带 %%NLS%% 的行， 在 NLS 关闭的情况下就会变为注释， 反之， 这些前缀就会自动删掉。 现在需要做的事情就是把 %%NLS%% 插到 pkg-plist 中的消息编录文件的那些行开头， 例如：

%%NLS%%share/locale/fr/LC_MESSAGES/foobar.mo
%%NLS%%share/locale/no/LC_MESSAGES/foobar.mo

　　在比较复杂的情形中， 您可能需要使用更高级的技术， 例如 动态生成装箱单 等。

6.5.3 处理消息编录目录

　　在安装消息编录文件时还有一个需要注意的地方。 这些文件会放到 LOCALBASE/share/locale 下与语言对应的目录中， 这些目录一般您的 port 不需要创建和删除。 最常用的语言的目录已经在 /etc/mtree/BSD.local.dist 中列出； 也就是说， 它们是基本系统的一部分。 其他一些语言的目录， 则由 devel/gettext 控制。 您最好查看一下 pkg-plist， 以确定是否正在安装某种不常用语言的文件。

6.7.1 X.Org 组件

　　在 Ports 套件中提供的 X11 实现是 X.Org。 如果您的应用程序用到了 X 组件， 则应将 USE_XORG 设为所需要的那些组件。 目前可用的组件包括：

　　bigreqsproto compositeproto damageproto dmx dmxproto evieproto fixesproto fontcacheproto fontenc fontsproto fontutil glproto ice inputproto kbproto libfs oldx printproto randrproto recordproto renderproto resourceproto scrnsaverproto sm trapproto videoproto x11 xau xaw xaw6 xaw7 xaw8 xbitmaps 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-server xp xpm xprintapputil xprintutil xpr oto xproxymngproto xrandr xrender xres xscrnsaver xt xtrans xtrap xtst xv xvmc xxf86dga xxf86misc xxf86vm.

　　最新的列表， 可以在 /usr/ports/Mk/bsd.xorg.mk 中找到。

　　The Mesa Project 是一个致力于自由的 OpenGL 实现的计划。 您可以使用 USE_GL 变量来让 port 依赖其不同的组件。 可用的选项包括： glut, glu, glw, glew, gl 和 linux。 为了实现向前兼容， 当使用 yes 时系统会自动将其映射为 glu。

USE_XORG=   xrender xft xkbfile xt xaw
USE_GL=     glu

　　许多 ports 会定义 USE_XLIB， 这会导致 port 依赖 50 多个动态连接库。 由于它出现于 X.org 模块化之前， 因此这个变量仅为向前兼容的原因提供， 新的 port 不应再使用它。

# 使用某些 X11 库并依赖字体服务和西里尔字体。
RUN_DEPENDS=   ${LOCALBASE}/bin/xfs:${X_FONTSERVER_PORT} \
               ${LOCALASE}/lib/X11/fonts/cyrillic/crox1c.pcf.gz:${X_FONTS_CYRILLIC_PORT}

USE_XORG=      x11 xpm

6.7.2 需要使用 Motif 的 port

　　如果您的 port 需要 Motif 库， 则应在 Makefile 中定义 USE_MOTIF。 默认的 Motif 实现是 x11-toolkits/open-motif。 用户可以通过设置 WANT_LESSTIF 变量来选择 x11-toolkits/lesstif 代替它。

　　bsd.port.mk 会将 MOTIFLIB 变量设置为到合适的 Motif 库的引用。 请使用补丁将您 port 中 Makefile 或 Imakefile 提到 Motif 库的地方改为 ${MOTIFLIB}。

　　有两种比较常见的情况：

• 如果 port 中将 Motif 在其 Makefile 或 Imakefile 表达为 -lXm， 则简单地将其替换为 ${MOTIFLIB}。

• 如果 port 在其 Imakefile 中使用 XmClientLibs， 则将其改为 ${MOTIFLIB} ${XTOOLLIB} ${XLIB}.

　　注意 MOTIFLIB (通常) 会展开为 -L/usr/X11R6/lib -lXm 或 /usr/X11R6/lib/libXm.a， 所以不需要在其前加入 -L 或 -l。

6.7.3 X11 字体

　　如果 port 将为 X Window 系统安装字体， 将这些字体放到 LOCALBASE/lib/X11/fonts/local。

6.7.4 通过 Xvfb 来获得虚拟的 DISPLAY

　　某些应用程序必须在有可用的 X11 显示的时候才能成功编译。 当编译的机器没有控制台时， 这会带来问题。 为了解决这个问题， 如果定义了适当的变量， 联编基础设施会启动采用虚拟帧缓存的 X server。 此时， 编译过程中将会传出可用的 DISPLAY。

USE_DISPLAY=  yes

6.7.5 桌面项

　　通过利用 DESKTOP_ENTRIES 变量， 可以很容易地在您的 port 中创建桌面项 (Freedesktop 标准)。 这些项会在类似 GNOME 或 KDE 这样的符合这一标准的桌面环境中显示在应用程序菜单中。 这样做会自动创建、 安装 .desktop 文件， 并将其加入 pkg-plist。 其语法为：

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

　　您可以在 Freedesktop 网站上 找到可用的分类名称。 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

6.9.1 在 port 中使用 Qt

　　当设置了 USE_QT_VER 时， 系统自动会给 configure 脚本传一系列有用的参数：

CONFIGURE_ARGS+= --with-qt-includes=${QT_PREFIX}/include \
                 --with-qt-libraries=${QT_PREFIX}/lib \
                 --with-extra-libs=${LOCALBASE}/lib \
                 --with-extra-includes=${LOCALBASE}/include
CONFIGURE_ENV+=  MOC="${MOC}" CPPFLAGS="${CPPFLAGS} ${QTCPPFLAGS}" LIBS="${QTCFGLIBS}" \
                 QTDIR="${QT_PREFIX}" KDEDIR="${KDE_PREFIX}"

　　如果将 USE_QT_VER 设为 4， 则还会进行下列配置：

CONFIGURE_ENV+= UIC="${UIC}" QMAKE="${QMAKE}" QMAKESPEC="${QMAKESPEC}"
MAKE_ENV+=      QMAKESPEC="${QMAKESPEC}"

6.9.2 组件的选择 (仅限 Qt 4.x)

　　当把 USE_QT_VER 设为 4 时， 就可以通过 QT_COMPONENTS 变量来指定对 Qt4 工具和函数库的依赖了。 通过在组件的名称后面添加 _build 或 _run 这样的后缀， 则可相应地将这依赖关系限于联编或运行时刻。 在没有指定后缀时， 系统默认在联编和运行时刻均依赖该组件。 通常情况下在指明函数库一类的组件时应不使用后缀， 联编工具类组件应使用 _build 后缀， 而插件类组件， 则应使用 _run 后缀。 下表中列出了一些最常用的组件 (全部可用的组件， 则在 /usr/ports/Mk/bsd.qt.mk 中的 _QT_COMPONENTS_ALL 列出)：

　　您可以通过在成功编译之后， 通过在主可执行文件上运行 ldd 来确定所需的库。

USE_QT_VER=    4
QT_COMPONENTS= gui moc_build qmake_build rcc_build uic_build

6.9.3 其他考虑

　　如果应用程序没有提供 configure 文件， 而是给了一个 .pro 文件， 则应这样：

HAS_CONFIGURE= yes

do-configure:
        @cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} \
                ${QMAKE} -unix PREFIX=${PREFIX} texmaker.pro

　　请注意， 这与系统提供的 BUILD.sh 中的 qmake 类似。 传递 CONFIGURE_ENV 能够确保 qmake 可以看到 QMAKESPEC 变量， 否则它可能无法正常工作。 qmake 会生成标准的 Makefile， 因此无需自行编写 build target。

　　Qt 应用程序通常会编写为能够跨平台使用， 通常 X11/Unix 并不是开发它的平台， 有时这会导致一些边边角角的问题， 例如：

• 缺少必要的 includepaths。 许多应用程序会使用托盘图标支持， 但忽略了这些头或库文件需要在 X11 目录中查找。 您可以通过命令行告诉 qmake 将这些头文件和函数库加入到搜索路径中， 例如：

  ${QMAKE} -unix PREFIX=${PREFIX} INCLUDEPATH+=${LOCALBASE}/include \
      LIBS+=-L${LOCALBASE}/lib sillyapp.pro
  

• 有问题的安装路径。 有时， 类似图标或 .desktop 文件这样的一些数据， 默认情况下没有安装到 XDG-兼容的程序会扫描的路径中。 editors/texmaker 就是一个这样的例子 - 请参考这个 port 的 files 目录中的 patch-texmaker.pro， 以了解如何在 Qmake 工程文件中修正这个问题。

6.10.1 变量定义 (只用于 KDE 3.x)

6.10.2 用于 KDE 4 的变量定义

　　如果您的应用程序需要使用 KDE 4.x， 则应将 USE_KDE4 设为所需组件的列表。 下面列出一些最常用到的组件 (最新的组件列表位于 /usr/ports/Mk/bsd.kde4.mk 中的 _USE_KDE4_ALL)：

　　KDE 4.x port 会安装到 ${KDE4_PREFIX}， 目前是 /usr/local/kde4， 以避免与 KDE 3.x ports 冲突。 这是通过指定 kdeprefix 组件来实现的， 它表示替换默认的 PREFIX。 不过， port 仍会遵循通过 MAKEFLAGS 环境变量设置的 PREFIX 以及其它 make 参数。

　　KDE 4.x ports 有可能和 KDE 3.x ports 冲突， 因此如果启用了 kdeprefix 组件， 它们会安装到 ${KDE4_PREFIX}。 目前 KDE4_PREFIX 的默认值是 /usr/local/kde4。 也可以将 KDE 4.x ports 安装到自定义的 PREFIX。 当 PREFIX 是通过 MAKEFLAGS 环境变量， 或直接在 make 命令行指定时， 它会替换 kdeprefix 提供的配置。

USE_CMAKE=     yes
USE_KDE4=      automoc4 kdelibs kdeprefix
USE_QT_VER=    4
QT_COMPONENTS= qmake_build moc_build rcc_build uic_build

6.11.1 变量定义

　　如果您的 port 需要 Java™ 开发包 (JDK™) 来完成联编、 支持运行， 甚至完成解开源代码包这样的工作， 就应该定义 USE_JAVA。

　　在 Ports Collection 中有许多不同的 JDK， 它们的版本各不相同， 或是来自不同的供应商。 如果您的 port 必须使用其中的某个特定的版本， 也可以予以定义。 最新的稳定版本是 java/jdk16。

　　下面是在设置了 USE_JAVA 之后， port 能够从系统中获得的配置：

　　您可以使用 java-debug make target 以获取用于调试 port 的信息。 大多数前述变量的值皆会予以呈现。

　　此外， 还会定义下述常量， 以确保所有的 Java port 均以一致之方式安装：

　　相关的项也会定义在 PLIST_SUB (在 第 7.1 节 中进行介绍) 和 SUB_LIST 中。

6.11.2 采用 Ant 进行联编

　　如果 port 采用 Apache Ant 进行联编， 则需要定义 USE_ANT。 如是， 则 Ant 将作为 子-make 命令来使用。 如果 port 未定义 do-build target， 则将默认依 MAKE_ENV、 MAKE_ARGS 和 ALL_TARGET。 的设置执行 Ant。 这类似于 第 6.3 节 中介绍的关于 USE_GMAKE 的机制。

　　若 jikes 被作为 javac 使用 (参见 第 6.11.1 节 中的 USE_JIKES)， 则 Ant 会自动将其用于 port 的联编过程。

6.11.3 最佳实践

　　如果您正移植某个 Java 库， 您的 port 应把 JAR 文件安装到 ${JAVAJARDIR}， 而其它文件则应放在 ${JAVASHAREDIR}/${PORTNAME} 下 (除了文档， 参见下文)。 要减少打包文件的尺寸， 您可以直接在 Makefile 中引用这些 JAR 文件， 具体做法是使用下面的语句 (此处的 myport.jar 是作为 port 一部分安装的 JAR 文件的名字)：

PLIST_FILES+= %%JAVAJARDIR%%/myport.jar

　　移植 Java 应用程序时， port 通常会希望将所有文件安装到同一目录 (包括其依赖的 JAR)。 这时强烈建议使用 ${JAVASHAREDIR}/${PORTNAME}。 移植软件的开发人员， 可以自行决定是否将所依赖的其它 JAR 安装到此目录， 或直接使用已经装好的那些 (来自 ${JAVAJARDIR})。

　　无论您正制作哪一类的 port (库或者应用程序)， 附加的文档都应安装到和其它 port 同样的位置。 已经知道， JavaDoc 会根据 JDK 版本的不同而产生不同的文件。 对于那些不打算强制使用某一特定版本 JDK 的 port 而言， 这无疑提高了制作装箱单 (pkg-plist) 的难度。 这是为什么强烈建议使用 PORTDOCS 宏的原因。 更进一步， 即使您能够预测 javadoc 将要生成的文件， 所需的 pkg-plist 的尺寸， 也是鼓吹使用 PORTDOCS 的一大理由。

　　DATADIR 的默认值是 ${PREFIX}/share/${PORTNAME}。 对 Java port 而言将 DATADIR 改为 ${JAVASHAREDIR}/${PORTNAME} 是一个好主意。 当然， DATADIR 会自动加到 PLIST_SUB 中 (在 第 7.1 节 有所介绍) 因此您可以在 pkg-plist 中直接使用 %%DATADIR%%。

　　撰写本文时， 对是应该从源代码联编， 还是直接安装预编译的 Java ports 安装包并没有明确的规定。 尽管如此， FreeBSD Java Project 的开发人员仍鼓励移植软件的开发者在不麻烦的情况下尽可能从源代码完成联编。

　　本节中所介绍的全部特性， 均是在 bsd.java.mk 中实现的。 如果您感觉自己的 port 需要更为复杂的 Java 支持， 请首先参阅 bsd.java.mk CVS 日志， 因为通常撰文介绍最新特性需要一些时间。 此外， 如果您认为所缺少的支持对许多其它 Java port 亦属有益， 请在 FreeBSD Java 语言邮件列表 对其进行讨论。

　　在 PR 中的 java 类别， 主要是用于 FreeBSD Java project 移植 JDK 本身之用。 因而， 提交您的 Java port 时， 应归入 ports 类别， 除非您正尝试解决的问题是 JDK 实现本身或 bsd.java.mk 的。

　　类似地， 您应参考 第 5.3 节 中所详述的关于 CATEGORIES 在 Java port 中的使用规则。

6.12.1 Apache

6.12.2 Web 应用

　　Web 应用程序应安装到 PREFIX/www/应用程序的名字。 为方便起见， 这个路径在 Makefile 和 pkg-plist 均以 WWWDIR 变量的形式提供。 在 Makefile 中可以使用 WWWDIR_REL 来表示包含了 PREFIX 的该变量值。

　　web 服务器进程所用的用户和用户组， 分别以 WWWOWN 和 WWWGRP 变量的形式提供， 如果您需要修改某些文件的属主的话。 这两个变量的默认值均为 www。 如果您的 port 希望使用其他值， 请使用 WWWOWN?= myuser 这种写法， 以便让用户能够更容易地修改它。

　　除非您的 port 必需使用 Apache， 否则不要将其写入依赖关系。 请尊重运行您的应用程序的用户选择 Apache 以外的其他 web 服务器的需求。

6.12.3 PHP

6.12.4 PEAR 模块

　　移植 PEAR 模块的过程非常简单。

　　使用 FILES、 TESTS、 DATA、 SQLS、 SCRIPTFILES、 DOCS 以及 EXAMPLES 这些变量来指明您希望安装的文件。 所有这里列出的文件都会自动安装到合适的位置， 并加入 pkg-plist。

　　在 Makefile 文件的最后一行引入 ${PORTSDIR}/devel/pear/bsd.pear.mk。

PORTNAME=       Date
PORTVERSION=    1.4.3
CATEGORIES=     devel www pear

MAINTAINER=     [email protected]
COMMENT=        PEAR Date and Time Zone Classes

BUILD_DEPENDS=  ${PEARDIR}/PEAR.php:${PORTSDIR}/devel/pear-PEAR
RUN_DEPENDS=    ${BUILD_DEPENDS}

FILES=          Date.php Date/Calc.php Date/Human.php Date/Span.php     \
                Date/TimeZone.php
TESTS=          test_calc.php test_date_methods_span.php testunit.php   \
                testunit_date.php testunit_date_span.php wknotest.txt   \
                bug674.php bug727_1.php bug727_2.php bug727_3.php       \
                bug727_4.php bug967.php weeksinmonth_4_monday.txt       \
                weeksinmonth_4_sunday.txt weeksinmonth_rdm_monday.txt   \
                weeksinmonth_rdm_sunday.txt
DOCS=           TODO
_DOCSDIR=       .

.include <bsd.port.pre.mk>
.include "${PORTSDIR}/devel/pear/bsd.pear.mk"
.include <bsd.port.post.mk>

6.18.1 介绍

　　许多不同版本的 wxWidgets 库之间是存在相互冲突的 (它们会安装同名的文件) 在 ports 系统中， 这一问题是通过将不同的版本以包含版本号后缀的名字安装来解决的。

　　这样做的一个最明显的缺点是， 应用程序必须进行修改， 才能找到所希望的版本。 幸运的是， 多数应用程序会调用 wx-config 脚本来确定需要的编译器和连接器选项。 这个脚本会随可用的版本不同而有不同的名字。 主要的应用程序都会尊重环境变量的配置， 或提供一个 configure 参数， 用以指定调用哪个 wx-config。 如果不是这样的话， 就需要对应用程序打补丁了。

6.18.2 版本的选择

　　为了让您的 port 使用指定版本的 wxWidgets， 可以定义两个变量 (如果只定义了一个， 则另一个会取默认值)：

　　下面是可用的 wxWidgets 版本， 以及对应的 ports：

　　在 表 6-24 中的变量， 可以设为下列值或由空格分隔的组合：

　　除此之外， 还有一些用以从可用的本那本中选择所希望的版本的变量。 这种变量也可以设为一组版本， 而靠前的版本的优先级更高。

6.18.3 选择组件

　　也有一些其他应用， 尽管它们本身并不是 wxWidgets 库， 但却与之相关。 这些应用程序可以在 WX_COMPS 变量中使用， 以下是可用的组件：

　　您可以为每个依赖的组件， 通过冒号分隔的后缀指定其类型。 如果没有指定， 则会使用默认的依赖类型 (参见 表 6-30)。 下面是可用的类型：

　　组件的默认依赖关系类型， 如下表所示：

USE_WX=       2.4
WX_COMPS=     wx contrib

6.18.4 Unicode

　　wxWidgets 库从其 2.5 版开始支持 Unicode 了。 在 ports 系统中， 这两种版本均有提供， 并可以通过下列变量来选择：

6.18.5 检测已安装的版本

　　要检测系统中安装的版本， 就需要定义 WANT_WX。 如果没有将其设置为特定的版本， 则组件将包含版本后缀。 HAVE_WX 变量在检测完成后会自动填入内容。

WANT_WX=        yes

.include <bsd.port.pre.mk>

.if defined(WITH_WX) || ${HAVE_WX:Mwx-2.4} != ""
USE_WX=         2.4
CONFIGURE_ARGS+=--enable-wx
.endif

USE_WX=         2.6
WX_COMPS=       wx
WANT_WX=        2.6

.include <bsd.port.pre.mk>

.if defined(WITH_WXPYTHON) || ${HAVE_WX:Mpython} != ""
WX_COMPS+=      python
CONFIGURE_ARGS+=--enable-wxpython
.endif

6.18.6 定义的变量

　　以下是一些可以在 port 中使用的变量 (这之前需要定义 表 6-24 中的至少一个变量)。

6.18.7 在 bsd.port.pre.mk 中进行处理

　　如果您需要在引用了 bsd.port.pre.mk 之后立即对一些变量进行处理， 则需要定义 WX_PREMK。

USE_WX=         2.4
WX_PREMK=       yes

.include <bsd.port.pre.mk>

.if exists(${WX_CONFIG})
VER_STR!=       ${WX_CONFIG} --release

PLIST_SUB+=     VERSION="${VER_STR}"
.endif

6.18.8 额外的 configure 参数

　　某些 GNU configure 脚本在只设置了 WX_CONFIG 环境变量时， 无法自动找到 wxWidgets， 而需要使用额外的参数来加以指定。 您可以使用 WX_CONF_ARGS 变量来给出这些参数。

6.19.1 介绍

　　许多不同版本的 Lua 库和相关的解释器之间是相互冲突的 (它们会安装同名的文件)。 在 ports 系统中， 这一问题是通过将不同版本的文件以不同的版本号作为后缀名解决的。

　　这样做最大的一个问题是， 每个程序都需要进行修改才能找到它所需要的版本。 不过， 通过将适当的参数传给编译器和连接器很容易解决这个问题。

6.19.2 选择版本

　　要让您的 port 使用指定版本的 Lua， 可以定义两个变量的值 (如果只定义了其中的一个， 则另一个会使用默认值)：

　　下面是目前 ports 系统提供的可用 Lua 版本和对应的目录：

　　在 表 6-34 中的变量， 可以设置为下面的版本之一， 或用空格分隔的若干版本：

　　除此之外， 也有一些用来从可用版本中选择推荐版本的其它变量。 这些变量也可以设置为一组版本， 而前面的版本优先级较高。

USE_LUA=      5.0-5.1
WANT_LUA_VER= 5.0

6.19.3 组件的选择

　　也有一些其它的应用， 尽管本身并不是 Lua 库， 但却与它们相关。 这些应用可以通过 LUA_COMPS 变量来指定。 可用的组件如下：

　　每个组件的依赖关系类型可以通过手工添加分隔符为冒号的后缀来指定。 如果不指定， 则会采用默认类型 (请参见 表 6-40)。 以下是可用的依赖关系类型：

　　组件的默认依赖关系类型如下：

USE_LUA=      4.0
LUA_COMPS=    lua ruby

6.19.4 检测系统中已安装的版本

　　要检测系统中已安装的版本， 您必须定义 WANT_LUA。 如果没有将其设定为具体的版本， 则组件会包含版本后缀。 在检测之后， HAVE_LUA 变量将设为检测到的版本。

WANT_LUA=       yes

.include <bsd.port.pre.mk>

.if defined(WITH_LUA5) || ${HAVE_LUA:Mlua-5.[01]} != ""
USE_LUA=        5.0-5.1
CONFIGURE_ARGS+=--enable-lua5
.endif

USE_LUA=        4.0
LUA_COMPS=      lua
WANT_LUA=       4.0

.include <bsd.port.pre.mk>

.if defined(WITH_TOLUA) || ${HAVE_LUA:Mtolua} != ""
LUA_COMPS+=     tolua
CONFIGURE_ARGS+=--enable-tolua
.endif

6.19.5 定义的变量

　　在 port 中可以使用下列变量 (在定义了 表 6-34 中至少一个变量之后)。

USE_LUA=        4.0
GNU_CONFIGURE=  yes
CONFIGURE_ENV=  CPPFLAGS="-I${LUA_INCDIR}" LDFLAGS="-L${LUA_LIBDIR}"

6.19.6 在 bsd.port.pre.mk 时进行处理

　　如果您需要在使用引用 bsd.port.pre.mk 之后就得到变量， 以便将其用于执行一些命令， 需要定义 LUA_PREMK。

USE_LUA=        5.0
LUA_PREMK=      yes

.include <bsd.port.pre.mk>

.if exists(${LUA_CMD})
VER_STR!=       ${LUA_CMD} -v

CFLAGS+=        -DLUA_VERSION_STRING="${VER_STR}"
.endif

6.22.1 卸载时停止服务

　　可以在卸载的过程中自动地停止服务。 我们建议只有在绝对必要， 例如必须在删除文件之前停止服务这类的情况下才使用这一功能。 通常来说， 决定是否在卸载时停止服务是系统管理员需要考虑的事情。 另外要注意， 这个功能也会影响升级过程。

　　需要时可以在 pkg-plist 中加入：

@stopdaemon doormand

　　这里的参数必须与 USE_RC_SUBR 变量的内容匹配。

7.2.1 清理空目录

　　一定要让 port 在卸载时进行清理空目录。 通常， 可以通过为所有由 port 创建的目录增加对应的 @dirrm 行来实现。 在删除父目录之前， 需要首先删除它的子目录。

 :
lib/X11/oneko/pixmaps/cat.xpm
lib/X11/oneko/sounds/cat.au
 :
@dirrm lib/X11/oneko/pixmaps
@dirrm lib/X11/oneko/sounds
@dirrm lib/X11/oneko

　　然而， 有时 @dirrm 会由于其它 port 使用了同一个目录而发生错误。 利用 @dirrmtry 可以只删除那些空目录， 而避免给出警告。

@dirrmtry share/doc/gimp

　　按照上面的写法， 将不会显示任何错误信息， 而且，即使在 ${PREFIX}/share/doc/gimp 由于其它 port 在其中安装了一些别的文件的时候， 也不会导致 pkg_delete(1) 异常退出。

7.2.2 如何建立空目录

　　在 port 安装过程中创建的空目录需要特别留意。 安装 package 时并不会自动创建这些目录， 这是因为 package 只保存文件。 要确保安装 package 时会自动创建这些空目录， 需要在 pkg-plist 中加入与 @dirrm 对应的行：

@exec mkdir -p %D/share/foo/templates

11.3.1 VuXML 数据库

　　当发现了安全漏洞时的一项重要而紧迫的步骤， 就是让使用 port 的用户群了解其危险。 这类通知有两重目的。 首先， 如果危害真的很严重， 可能理性的办法就是立即应用一项缓解措施， 例如， 停止受到影响的服务， 甚至完全删除 port， 直到问题被修正为止。 其次， 许多用户只是偶尔升级所安装的软件包， 通过通知， 他们能够知道已经到了 必须 更新软件的时候， 因为已经有了修正这些问题的版本了。

　　由于现有的 port 数量极其庞大， 为每一个问题都发布安全公告， 毫无疑问地会发表和狼来了一样多的安全公告， 并增大受众在真的发生严重的问题时忽略问题的可能。 因此， 在 port 中发现的安全漏洞， 会在 FreeBSD VuXML 数据库 中记录。 安全官团队成员会持续地追踪这个数据库的修改， 以了解需要他们注意的内容。

　　如果您是 committer， 则可以自行更新 VuXML 数据库。 这样， 您就能够同时帮助安全官团队， 并尽早将至关重要的信息传达给用户群体。 然而， 如果您不是 committer， 或者您相信自己发现了一个异常严重的漏洞， 或者由于其它情况， 请不要由于按照 FreeBSD 安全信息 页面上的方法联系安全官团队。

　　现在您选择了一条艰难的路。 正如其名称所暗示的那样， VuXML 数据库本质上是一个 XML 文档。 其源文件 vuln.xml 被保存在 security/vuxml port 的目录中。 所以， 它的全名是 PORTSDIR/security/vuxml/vuln.xml。 每当您发现 port 中的安全漏洞时， 请把新的纪录加入到那个文件中。 在熟悉 VuXML 之前， 您最好先看看是否有类似的您发现的问题的其它记录， 并复制它作为模板。

11.3.2 VuXML 简介

　　XML 是一个复杂的语言， 它远远超越了这本书的范围。 不过， 只需了解标记的命名规则， 就能 VuXML 记录的结构有一个大体的了解了。 XML 标记的名字应出现在一对尖括号之间。 每一个 <tag> 必须有一个对应的 </tag>。 标记可以嵌套， 如果嵌套的话， 内层的标记必须在外层标记之前结束。 这就形成了一个标记的层次结构， 也就是关于它们之间如何嵌套的规则。 听起来很像 HTML， 是不是？ 最主要的区别在于， XML 是可扩展的 (eXtensible)， 例如通过定义新的标记等等。 由于其结构的内在性质， XML 能够赋予无组织的数据新的形态。 VuXML 是专门为描述安全漏洞设计的语言。

　　现在让我们来观察一个实际的 VuXML 记录：

<vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> 
  <topic>Several vulnerabilities found in Foo</topic> 
  <affects>
    <package>
      <name>foo</name> 
      <name>foo-devel</name>
      <name>ja-foo</name>
      <range><ge>1.6</ge><lt>1.9</lt></range> 
      <range><ge>2.*</ge><lt>2.4_1</lt></range>
      <range><eq>3.0b1</eq></range>
    </package>
    <package>
      <name>openfoo</name> 
      <range><lt>1.10_7</lt></range> 
      <range><ge>1.2,1</ge><lt>1.3_1,1</lt></range>
    </package>
  </affects>
  <description>
    <body xmlns="http://www.w3.org/1999/xhtml">
      <p>J. Random Hacker reports:</p> 
      <blockquote
        cite="http://j.r.hacker.com/advisories/1">
        <p>Several issues in the Foo software may be exploited
          via carefully crafted QUUX requests.  These requests will
          permit the injection of Bar code, mumble theft, and the
          readability of the Foo administrator account.</p>
      </blockquote>
    </body>
  </description>
  <references> 
    <freebsdsa>SA-10:75.foo</freebsdsa> 
    <freebsdpr>ports/987654</freebsdpr> 
    <cvename>CAN-2010-0201</cvename> 
    <cvename>CAN-2010-0466</cvename>
    <bid>96298</bid> 
    <certsa>CA-2010-99</certsa> 
    <certvu>740169</certvu> 
    <uscertsa>SA10-99A</uscertsa> 
    <uscertta>SA10-99A</uscertta> (16)
    <mlist msgid="[email protected]">http://marc.theaimsgroup.com/?l=bugtraq&amp;m=203886607825605</mlist> (17)
    <url>http://j.r.hacker.com/advisories/1</url> (18)
  </references>
  <dates>
    <discovery>2010-05-25</discovery> (19)
    <entry>2010-07-13</entry> (20)
    <modified>2010-09-17</modified> (21)
  </dates>
</vuln>