分类：
2008-04-08 16:35:31
本章介绍两种生成 OpenSolaris 的常用方法：nightly(1)/bldenv(1) 和 make(1)/dmake(1)。前者对完整或增量生成整个 工作区的每个步骤提供较高程度的自动和精确控制。直接使用 make(1) 或 dmake(1) 提供的自动控制较低，但生成单个组件的速度更快。第 4.1 节适用于这两种方法；第 4.2 节介绍 nightly(1) 和 bldenv(1)，第 4.3 节介绍如何使用低级 make(1) 目标。最后，第 4.4 节介绍完整生成的结果以及如何使用这些中间产品。本章中的说明适用于 ON 和类似整合，包括 SFW 及网络存储 (Network Storage, NWS)。其他整合的生成过程可能完全不同，应在此处进行引入。
本节介绍一些影响所有 ON 生成的环境变量（无论生成方法如何）。有关影响 nightly(1) 和 bldenv(1) 的环境变量和文件的信息，请参见 4.2 使 用 nightly 和 bldenv。
此变量通常由 TeamWare（Sun 的内部源代码管理系统）使用。尽管不使用 TeamWare 的 工作区不需要此变量，但在设置其他变量时有时会引用此变量。应将其设置为工作区的根。强烈建议使用 bldenv(1) 来设置此变量，因为它还将同时设置其他几个重要变量。有关 bldenv(1) 的更多信息，请参见第 .3.3.2 节。
必须将此变量设置为工作区中的 ON 源文件树的根，即 ${CODEMGR_WS}/usr/src。此变量供许多 makefile 和 nightly(1) 使用。仅在生成时才需要此变量。bldenv(1) 将为您正确设置此变量。
uname -p 指定的计算机的指令集体系结构，例如 sparc、i386。仅在生成时才需要此变量。bldenv(1) 将为您正确设置此变量，请不要更改。如果您愿意，也可在 dot 文件中设置此变量，并使用它定义所需的 PATH 及任何其他变量。如果手动设置此变量，请勿将其设置为非 ``/usr/bin/uname -p'' 输出（所使用的特定计算机上）的任何内容：
正确：
MACH=`/usr/bin/uname -p`
错误：
MACH=sparc
用于生成的样例区域的根。makefile 通过生成命令和其他目标，将头文件和库的安装定向到此区域并指示对这些文件的引用。应使用 $CODEMGR_WS 来表示该变量。有关样例区域的更多信息，请参见第 4.4.1 节。如果使用 bldenv(1)，则此变量将设置为 ${CODEMGR_WS}/proto/root_${MACH}。
PARENT_ROOT 是父工作区的样例区域。使用此变量可通过引用父工作区中的已安装文件，在子工作区中执行部分生成。设置此变量为可选操作。
此变量与 OpenSolaris 无关，但是，为使生成正常工作，make(1) 必须可以访问本节所述的环境变量的内容。因此，应设置 MAKEFLAGS 环境变量，并使其至少包含 ``e''。b ldenv(1) 将为您设置此变量；仅在生成时才需要此变量。如果直接通过 make(1) 或 dmake(1) 进行生成，则可使用 ``make -e'' 来代替此变量，但强烈建议您使用 MAKEFLAGS。
缺省情况下， /ws/onnv-tools/SUNWspro/SOS8（该路径在 Sun 内部使用）中可能会安装工作编译器。可以设置此变量以覆盖该位置；由于您可能未在该缺省位置中安装编译器，因此通常需要将此变量设置为 /opt/SUNWspro。通过查看 usr/src/Makefile.master ，可以了解此变量的工作方式；但是，如果需要覆盖该缺省位置，则应通过该环境变量来执行。请注意， opensolaris.sh 已将此变量设置为该值。
``V'' 表示版本。在 Sun 中，在 ${SPRO_ROOT} 下安装了多个编译器版本，以便为生成较早版本的源文件提供支持。由于编译器本身可能位于 ${SPRO_VROOT}/bin/cc 中，因此您很可能需要将此变量设置为 /opt/SUNWspro。请注意， opensolaris.sh 已将此变量设置为该值。
缺省情况下，GNU C 编译器用于为 amd64 系统生成 64 位内核。缺省情况下，如果在 x86 主机上生成，则生成系统会假定 /usr/sfw 中安装了工作 amd64 gcc。尽管建议不要这样做，但是通过将此变量设置为 gcc 安装根目录，可以使用其他 gcc。有关更多信息，请参见 usr/src/Makefile.master 。
这些变量用于控制 gcc 的使用。__GNUC 控制 gcc 的使用以生成 i386 和 sparc（32 位）二进制文件，而 __GNUC64 控制 gcc 的使用以生成 amd64 和 sparcv9（64 位）二进制文件。将这些变量设置为空值， 可以 使用 gcc 来生成相应的二进制文件。将这些变量设置为 '#'，可将 Studio 用作主编译器。缺省设置将 Studio（并行调用了 gcc）用作“阴影” 编译器，以确保代码保持警告和错误 clean。
此变量指示 ON makefile 是否查找不公开的源代码树。通常，nightly(1) 和 bldenv(1) 会自动设置此变量。有关更多详细信息，请参见 3.2.8 未包含 的源文件。
生成任何整合包括多个步骤；ON 的生成过程需要创建样例区域、编译和链接二进制文件、生成 lint 库和对源文件执行 lint 操作、生成软件包和 BFU 归档文件以及检验头、打包和样例区域更改。幸运的是，一个称为 nightly(1) 的实用程序可以自动完成所有这些步骤及其他任务。该实用程序由一个环境文件控制，此环境文件通过 bldenv(1) 实现格式共享。本节介绍 nightly(1) 执行的操作、不会执行的操作及其使用方法。
nightly(1) 可以自动执行大多数生成过程和源级别检查过程。它可生成源文件、生成 BFU 归档文件、生成软件包、运行 lint(1)、执行语法检查以及创建并检查样例区域。它不会执行任何运行时测试，如单元、功能或回归测试；理论上，必须在专用系统上分别执行这些测试。
无论其名称如何，均可手动或通过 cron(1M) 随时运行 nightly(1)；您必须亲自运行该实用程序，或安排在每次要执行生成时运行一次。nightly(1) 不会启动任何守护进程或重复性后台活动：它会按照您的指示执行一次，然后停止。
每次运行后，nightly(1) 都会详细记录所运行的命令及其输出；相关信息通常位于 $CODEMGR_WS/log/log.MMDD/nightly.log 中（其中 MMDD 表示日期），但 可根据需要进行更改。如果已存在此类日志，则 nightly(1) 会对其重命名。
除详细日志外，您（实际上是 MAILTO 环境变量中指定的地址）还会在 nightly(1) 完成时收到一份简短的完成报告。该报告将通知您有关检测到的任何错误或警告信息，以及完成每个步骤所需的时间。该报告会将错误和警告列为与以前生成（如果存在一个）的差异；这样您便可以查看更改（如果有）的效果。它还意味着，如果尝试一个生成，但该生成失败，然后更正问题并重新生成，将会显示与以下类似的信息：
< dmake:Warning: Command failed for target `yppasswd'
< dmake:Warning: Command failed for target `zcons'
< dmake:Warning: Command failed for target `zcons.o'
< dmake:Warning: Command failed for target `zdump'
请注意，``<'' 表示此输出用于以前版本。如果输出前面带有 ``>''，则表示该输出与最新版本关联。采用这种方式，即可查看是否已更正所有问题或引入了新问题。
nightly(1) 接受多种控制其行为的选项和标志。许多选项用于控制 nightly(1) 是否执行可自动完成的每个步骤。可以在环境文件或命令行中指定这些选项；应首选在命令行中指定选项。请参见 nightly(1)。
nightly(1) 可读取一个包含用于生成的环境定义集的文件。该文件是一个简单的 shell 脚本，但通常仅包含变量赋值。在 2.5 环境变量一节和以下 4.2.3 变量中介绍的所有变量，都可在 nightly(1) 环境文件中设置；但是，常见做法是使用开发者、门管理员或 opensolaris 环境文件，并根据需要修改其中一个文件以满足您的要求。然后，将所得的环境文件的名称作为最后一个参数传递给 nightly(1)。usr/src/tools/env 中提供了环境文件样例。
尽管可在 nightly(1) 环境文件中设置任何环境变量，但本节仅列出了 nightly(1) 直接用于控制其操作的环境变量以及通常会更改的环境变量。有关变量和选项的完整列表，请参见 nightly(1)。
虽然 nightly(1) 可以自动完成整个生成过程（包括源级别检查和生成其他生成产品），但它并非总是必需的。如果您正在处理单个子目录，并且仅希望生成或 lint 该子目录，则通常可以直接执行此操作，而不必使用 nightly(1)。这尤其适用于内核，并且如果未对 工作区的任何其他部分执行更改，则在中间测试过程中还可利用该方法仅生成并安装内核。有关安装测试内核的更多信息，请参见第 5.2 节。
在工作区的任何部分上直接使用 make(1) 之前，需要正确设置环境。可以使用 bldenv(1) 完成此操作；有关此命令的更多信息，请参见 3.4.1 准 备工作和 4.2 使用 nightly 和 bldenv。
由于 makefile 会使用许多 make(1) 功能，因此某些版本的 make 将无法正常工作。具体而已，不能使用 BSD make 或 GNU make 来生成工作区。 OpenSolaris 工具分发中提供的 dmake(1) 可以正常工作，/usr/ccs/bin 中随 Solaris 和某些其他分发一同提供的 make(1) 也可以正常工作。如果 dmake 的版本较旧（或在某些情况下较新），则可能会意外失败。尽管 dmake(1) 和 make(1) 均可使用，但通常建议使用 dmake(1)，因为 dmake(1) 可以并行运行多个任务，甚至可将任务分发到其他生成服务器。这样可以显著减少生成时间。
使用整个 uts 目录，可以在特定生成子目录中运行 make 命令（参见第 3.3.2 节至第 3.3.6 节），以便仅完成只在该特定子目录上请求的生成步骤。大多数 cmd 和部分 lib 子目录也允许执行此操作；但是，尚未正确配置某些 makefile 以重新生成所有相关性。通常，使用新式对象文件布局（参见第 3.3.2 节）的所有子目录应正常工作。
有几个有效目标适用于所有目录；要查明适用于所关注目录的目标和可用的其他目标，需要读取该目录的 makefile。
以下是一些通用目标：
all
在对象目录中生成所有派生对象。
install
在 ${ROOT} 定义的样例区域中安装派生对象。
install_h
在 ${ROOT} 定义的样例区域中安装头文件。
clean
删除中间对象文件，但不删除“完成的”派生文件，例如可执行程序、库或内核模块。
clobber
删除所有派生文件。
check
执行特定于源的检查，例如源和头样式一致性。
lint
生成 lint 库，并针对将用于在当前目录中生成对象的所有代码运行所有相应的 lint 操作。
完整生成的源文件树本身并无太大用处；构成系统的二进制文件、脚本和配置文件仍然分散在整个树中。makefile 提供了 install 目标以生成样例区域和软件包树，并且其他实用程序可用于构建生成产品的其他聚集体，以便为集成到整个 Wad Of Stuff 生成，或安装到一个或多个系统中进行测试和进一步开发做好准备。nightly(1) 程序可以自动生成每个生成产品。或者，可使用安装程序（参见第 5.2 节）从完整生成的 usr/src/uts 直接构造内核安装归档文件。
第 4.4.1 节介绍了样例区域、最基本的生成对象集合以及生成系统生成的第一个对象。第 4.4.2 节介绍了 BFU 归档文件，该文件使用基于 OpenSolaris 的完全分发安装将系统升级到最新的 ON 位。第 4.4.3 节介绍了 ON 可传送项的软件包树的构造。
安装目标使二进制代码和头安装在称为样例区域的分层结构中。由于样例区域中的所有项都使用其相对于样例区域根的常规路径进行安装，因此完整的样例区域与 ON 位的完全系统安装类似。但是，任意用户都可以构造样例区域，因此其内容的拥有权和权限将与实时系统中的拥有权和权限不匹配。样例区域的根由环境变量 ROOT 定义，其缺省值为 /proto。如果使用 bldenv(1) 设置环境，则 ROOT 的缺省值为 ${CODEMGR_WS}/proto/root_${MACH}。
如果需要将生成的特定文件复制到实时系统，则样例区域会很有用。样例区域还通过 protocmp 和 checkproto 等工具与父项的样例区域和打包信息进行比较，以便检验是否由于更改了源而仅更改了预期提供的文件。
protocmp 未提供手册页。其调用如下所示：
