Second life 客户机，第 1 部分: 玩转 Second Life

Linden Lab 所开发的 Second Life 查看器程序的开源发行版为我们提供了宝贵的机会，可以了解封闭开发模型与开源开发模型的力量对比。本文是系列文章的第一篇，将简要介绍这些开发风格之间的区别，并讨论在设置自己的编译环境中都涉及哪些问题。

Second Life 是一个虚拟世界，通过客户机软件和主机服务器的组合进行维持。这非常类似于 “大型多人在线游戏”（MMO），不过它具有一些与众不同的特性：几乎所有的内容都是用户提供的。另外一点与众不同的是：Linden Labs 最近宣布这个客户机软件以开源的形式发布。这种事情在商业 MMO 应用程序中即使发生过，也是非常罕见的。它选择的具体许可证是 GPL v2，一个例外是 FLOSS 软件。

在本系列文章中，我们将简要介绍客户机（按照 Linden 术语来说就是 “查看器”），并探索开发环境、文档和其他方面的内容。习惯使用开源环境的开发人员有时会因商业环境中的一些差别而分心，这个项目提供了大量的机会来探索两者之间的平衡。当然，研究程序的最佳方法就是使用这个程序来做些事情，因此本系列文章将研究一些有所不同的代码。

Second Life 系统需求

Second Life 客户机可以在 Microsoft® Windows、Mac® OS X 和 Linux® 系统上使用（现在还可在其他一些平台上运行）。在本文中我们将介绍如何在 Linux 上构建和开发，最终进行交叉编译，这样用户就可以在其他平台上使用该客户机了。要运行客户机，您的系统需要具有合理的 3D 硬件，以及一个相当快的 CPU；当然，速度越快越好。对于 Linux 环境来说，程序需要硬件提供直接渲染支持；大部分 nVidia 或 ATI 显卡都有一些版本的驱动程序能够支持这种功能。

Linden 最初的测试是在 Debian、Fedora Core 4 和 Knoppix 上完成的；我在 SUSE 10.1 上也进行了测试，不过鼓励您使用自己喜欢的发行版，可以向 Linden 开发人员支持论坛（请参见 参考资料 中的链接）报告自己遇到的问题。

构建 Second Life 客户机并不那么简单，目前还不能说是一帆风顺的，不过曾经一直封闭的软件包选择开源也是很正常的。举例来说，与大家在尝试早期的 Mozilla 发行版时的恶梦般的经历相比，这就像是在公园中散步一样轻松。

作为一个 alpha 版本，它依然在不断变化之中。您可以在 Second Life Wiki 编译查看器（Linux）页面上（请参见 参考资料 中的链接）找到最新的软件包列表和构建说明。

这些说明指出构建时间大约需要 “两小时”。我在不同 CPU 和 Linux 安装中多次进行了构建，实际的构建时间从 1 小时 20 分钟到 25 分钟不等 —— 而且没有一个完全没有问题。下面是我碰到的一些有趣问题：
依赖于早期的软件包。客户机知道不能使用 gcc 4。您需要使用 gcc 3.4。
使用专有软件包，例如 fmod 音频工具包；尽管它是免费的，不过并非开源。类似地，客户机最初实际上只能使用 Kakadu JPEG 实现，而不能使用 OpenJPEG（有关这个问题的更多信息，请参看 参考资料）。
依赖于非标准软件包，例如 SCons。这是 GNU make 的一个替代品，在很多 Linux 安装中都可以使用，不过很少是默认安装的。使用 SCons 来构建程序轻而易举，不过在开始之前需要做一些准备工作。
特殊或其他构建需求：举例来说，ELFIO 普通构建会生成一个静态库，而 Second Life 查看器需要使用一个共享库。Second Life 需要 xmlrpc-epi，不过您必须要对此应用特定的补丁。
冲突：就 xmlrpc-epi 来说，它会与 xmlrpc-c 冲突。尽管它很难成为客户机的默认设置，但是我需要的 3D 图形加速驱动程序破坏了 OpenGL 程序的编译过程，这会导致需要使用相当复杂的解决方案。

如果您习惯使用开源开发环境，那么商业构建过程看起来可能会显得非常糟糕。为什么它们会出现这些依赖性呢？为什么在使用软件之前需要这么多设置呢？

问题部分在于（对于商业应用程序来说是很有道理的）假设您只能在已经为构建配置好适当环境的机器上来构建查看器。当您控制开发系统时，很容易确保每个开发工作站或构建机器具有所有必需的库。在第一次构建 OpenGL 客户机的过程，大部分时间都花在设置环境上。

您可以手工设置整个环境，不过这需要相当多的额外工作。本地补丁（在 xmlrpc-epi 代码中）的存在和很多系统上未提供的软件包的多样性意味着在可以编译 Second Life 代码之前需要做大量的编译工作，然后才能使继续。这在构建开源项目时是完全不存在的；尤其不一样的是这一切不能在一个 “配置” 阶段中完成，因为根本就不存在这样一个过程。如果您的系统已经正确设置，那么每次构建时就可以节省大量时间，不过如果环境未设置好，就会浪费许多时间。

一旦设置好正确的环境之后，实际的过程和最常见的一些步骤就都是自动完成的了，您只需要按几个按钮并继续执行即可。源代码下载页面（请参看 参考资料）中有一个表给出了各版本需要下载的全部内容；所支持的各种平台的预构建库也列于此表的行中，但需另行下载。

尽管设置工作并不完全是自动化的，但相对而言，这个过程并不需要非常频繁地反复进行。在这方面，Linden Labs 可能也有一个很好的自动化系统，用于创建各种 Second Life 构建环境。

区别在于商业开发人员通常可以假设能够对构建环境拥有完全控制权，而开源软件够得到广泛采用，往往需要能够在各种平台上都能够构建，这很合理：在构建 gcc 3.4 以便构建 Second Life 客户机时，我只需要运行 configure、make 和 make install 这三条命令就万事大吉了。

要构建 Second Life 客户机，却没法只是简单地运行 configure、make 和 make install —— 因为它根本就没有使用 make。

认识 SCons

用来构建 Second Life 查看器的程序称为 SCons，这是一个可以替代 make 的程序。

在开始使用 Second Life 之前，我从来没有听说过 Scons。最初见到 Scons，我的第一反应是 “噢，谁能告诉我，为什么他们要使用一些怪异的专有程序，而不使用 make 呢？”这个声音在我耳边足足回响了 5 分钟，也许是 10 分钟。在浏览了这个项目的 Web 页面之后，我意识到自己似乎错了。首先，SCons 不是一个 “专有” 程序。尽管它既不是 make，也不兼容 make，但我们大概不能把一个使用开源许可证发布的自由产品称为 “专有” 软件。

不过还有一个问题，为什么要使用一个大多数用户都没有的程序（我的 Linux 安装是 “完全安装”，上面并没有这个软件，不过我在安装介质上找到了 RPM 文件），而不选择一个大家都习惯使用的程序呢？答案有很多个；坦白地说，SCons 从技术上来说要优于 make。当然，如今技术优越性并不代表一切；它还有很多众所周知、广泛适用的优点。然而，这些优点在传统开源环境中会表现得更加强大，您可能希望其他人了解您的项目并对其进行深入研究；在传统企业环境中，这些优点就无法表现的那么强大，此时可能仅仅是证明它能够让员工更快地完成自己的工作就需要大约 1 周左右的培训。对于大型构建来说（Second Life 查看器就属于此类），并行和分布式构建各自的优点都足以补偿漫长的学习周期所带来的代价。

如果您想要了解构建过程，需要了解的主要问题是 SCons 使用的项目文件（称为 “SConstruct”）是一个 Python 程序。由于 SConstruct 文件都是 Python 程序，因此可以自行完成很多内部配置检查。您不需要运行 configure 来构建这些文件；部分原因是由于 SConstruct 程序自行正确地设置了很多构建参数。 特定于架构的优化
此时可能会自然而然地出现一个问题，为什么没有代码将 3D 渲染功能转交给（比如说）Cell BE 芯片上的 SPE 呢？实际上，答案非常简单；没有几个用户使用的系统具备两个协处理器，还有一个方便的 GPU 可以用来处理 3D 渲染功能。举例来说，PS3 上的 Linux 并不能访问系统中的 GPU。对于大部分用户来说，要开发提高性能的特性需要耗费大量的时间。这就是说，尽管这在商业上也许是不可行的，但是可以成为爱好者投身其中从的一个有趣项目。



阅读 SConstruct 文件可以让您深入了解构建过程。在命令行中传递的选项至少已部分地在文件注释中得到了解释。特别有趣的是，文件头中的建议调用都提供了针对所有受支持平台的版本，而不仅仅是主机平台。

默认行为是使用 SConstruct 文件中嵌入的主机列表来进行分布式构建。这是一个有趣的选择，或许也是人们选用 SCons 的原因之一；make 的大部分版本都不能支持分布式构建，不过如果您有一个编程小组正在从事某个构建时间超过 1 个小时的项目，您很可能会认为分布式构建是一个非常重要的特性。

构建

Linden 构建过程依赖于从很多不同地方（很多 Linux 包都存储自己的包含文件）拷贝的文件，在 Linden 构建树中这些文件被拷贝到一个统一的位置处。在开发者 Wiki 上可以找到相关说明（请参看参考资料）。如果您使用了预构建的库，那么准备构建过程所用的样例 shell 命令如下所示：

清单 1. 拷贝包含文件
cp -a /usr/include/atk-1.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/include/gtk-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/gtk-2.0/include/* ${SLSRC}/libraries/i686-linux/include/gtk-2.0/
cp -a /usr/include/glib-2.0 ${SLSRC}/libraries/i686-linux/include/
cp -a /usr/lib/glib-2.0/include/* ${SLSRC}/libraries/i686-linux/include/glib-2.0/
cp -a /usr/include/pango-1.0 ${SLSRC}/libraries/i686-linux/include/



这假设 ${SLSRC} 会引用您解压缩 Second Life 客户机树的位置。实际上，上面的方法对我来说并不适用，因为在我的系统上，所有 /usr/ 路径都替换成了 /opt/gnome/；举例来说，gtk 包含文件可以在 /opt/gnome/include/gtk-2.0 中找到。这非常容易修正，不过这是一个例子，人们需要编写 configure 脚本来完成这种工作。要让一切顺利进行，您需要多尝试几次。

在构建过程页面上，还有一些类似的说明供您采纳，不过所下载的预构建库软件包使您可以跳过实际构建过程。您可以使用其他两个选项来调用 SCons：

清单 2. 调用 SCons
$ cd indra
$ scons DISTCC=no BTARGET=client BUILD=release



另外两个选项指定了是否要进行分布式构建（此处选择不使用分布式构建，除非您希望进行大量网络准备工作），其目标是要构建程序（客户机是您惟一具有源代码的东西），以及要生成的是哪种构件（举例来说，您可以构建出一个调试版本）。如果您希望一次运行多个作业，可以简单地将 -j 3 添加到 scons 命令行中，这与 GNU make 非常类似。





目录树

Second Life 查看器有两个主目录：一个是 libraries 目录，其中保存了支持代码和头文件；另外一个是 indra 目录，其中包含了查看器本身的源代码，以及 Linden 所提供的支持库。

.o 文件都放在 /tmp 中；具体来说，SCons 会在 /tmp/username 中创建一个目录树，并将输出文件放到这个目录中，从而避免在非绝对必要的情况下修改构建树。相对而言，二进制文件本身保存在 indra/ 中的 newview/ 子目录中。Linux 二进制文件在未经过 strip 处理时大约是 131MB。经过 strip 处理之后，就苗条得多了，只有 26MB。