已向代码中添加了很多环境变量,但是,他基本上还是执行同一功能。但是,假如现在要要编译任何标准的 GNU 基于 autoconf 的源代码 tar 压缩包,只需简单地将该文档复制到一个新文档(用合适的名称来反映他所编译的新包名),然后将 "$A" 和 "$P" 的值更改成新值即可。任何其他环境变量都自动调整成正确配置,并且脚本按预想工作。虽然这很方便,但是代码更有改进余地。这段代码比我们开始创建的 "transcript" 脚本要长很多。既然任何编程项目的目标之一是减少用户复杂度,所以最好大幅度缩短代码,或至少更好地组织代码。能够用一个巧妙的方法来做到这点 -- 将代码拆成两个单独文档。将该文档存为 "sed-3.02.ebuild":
sed-3.02.ebuild
|
第一个文档不重要,只包含那些必须在每个包中配置的环境变量。下面是第二个文档,他包含操作的主要部分。将他存为 "ebuild",并使他成为可执行文档:
ebuild 脚本
|
既然已将构建系统拆成两个文档,我敢打赌,您一定在想他的工作原理。基本上,要编译 sed,输入:
$ ./ebuild sed-3.02.ebuild
当执行 "ebuild" 时,他首先试图 "source" 变量 ""。这是什么意思?还记得 前一篇文章所讲的吗:"" 是第一个命令行自变量 -- 在这里,是 "sed-3.02.ebuild"。在 bash 中,"source" 命令从文档中读入 bash 语句,然后执行他们,就好象他们直接出现在 "source" 命令所在的文档中相同。因此,"source " 导致 "ebuild" 脚本执行在 "sed-3.02.ebuild" 中定义 "$P" 和 "$A" 的命令。这种设计更改确实方便,因为假如要编译另一个程式,而不是 sed,能够简单地创建一个新的 .ebuild 文档,然后将其作为自变量传递给 "ebuild" 脚本。通过这种方式,.ebuild 文档最终很简单,而将 ebuild 系统复杂的操作部分存在一处,即 "ebuild" 脚本中。通过这种方式,只需编辑 "ebuild" 脚本就能够升级或增强 ebuild 系统,同时将实现细节保留在 ebuild 文档之外。这里有一个 gzip 的样本 ebuild 文档:
gzip-1.2.4a.ebuild
|
五。添加功能性
好,我们正在取得进展。但是,我还想添加某些额外功能性。我希望 ebuild 脚本再接受一个命令行自变量:"compile"、"unpack" 或 "all"。这个命令行自变量告诉 ebuild 脚本要执行构建过程的哪一步。通过这种方式,能够告诉 ebuild 解包档案,但不进行编译(以便在开始编译之前查看源代码档案)。要做到这点,将添加一条 case 语句,该语句将测试 "",然后根据其值执行不同操作。代码如下:
ebuild,修定本 2
|
已做了很多改变,下面来回顾一下。首先,将编译和解包步骤放入各自的函数中,其函数名分别为 ebuild_compile() 和 ebuild_unpack()。这是个好的步骤,因为代码正变得越来越复杂,而新函数提供了一定的模块性,使代码更有条理。在每个函数的第一行,显式 "cd" 到想要的目录,因为,随着代码变得越来越模块化而不是线形化,出现疏忽而在错误的当前工作目录中执行函数的可能性也变大。"cd" 命令显式地使我们处于正确的位置,并防止以后出现错误 - 这是重要的步骤,特别是在函数中删除文档时更是如此。
文章整理:西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢!




