Bash 实例之ebuild

最新推荐文章于 2018-06-29 10:37:54 发布

lyuncxw

最新推荐文章于 2018-06-29 10:37:54 发布

阅读量550

点赞数

分类专栏： linux

linux 专栏收录该内容

30 篇文章 0 订阅

订阅专栏

进入 ebuild 系统

我真是一直期待着这第三篇、也是最后一篇 Bash实例文章，因为既然已经在第 1 篇和第 2 篇中讲述了 bash 编程基础，就可以集中讲述象 bash应用开发和程序设计这样更高级的主题。在本文中，将通过我花了许多时间来编码和细化的项目，GentooLinux ebuild 系统，来给您大量实际的、现实世界的 bash 开发经验。

我是 Gentoo Linux（目前还是 beta 版的下一代 Linux OS）的首席设计师。我的主要责任之一就是确保所有二进制包（类似于RPM）都正确创建并一起使用。正如您可能知道的，标准 Linux系统不是由一棵统一的源树组成（象 BSD），而实际上是由超过 25个协同工作的核心包组成。这其中包括：

包	描述
linux	实际内核
util-linux	与 Linux 相关的杂项程序集合
e2fsprogs	与 ext2 文件系统相关的实用程序集合
glibc	GNU C 库

每个包都位于各自的 tar压缩包中，并由不同的独立开发人员或开发小组维护。要创建一个发行版，必须对每个包分别进行下载、编译和打包处理。每次要修复、升级或改进包时，都必须重复编译和打包步骤（并且，包确实更新得很快）。为了帮助消除创建和更新包所涉及的重复步骤，我创建了ebuild 系统，该系统几乎全用 bash 编写。为了增加您的 bash知识，我将循序渐进地为您演示如何实现该 ebuild系统的解包和编译部分。在解释每一步时，还将讨论为什么要作出某些设计决定。在本文末尾，您不仅将极好地掌握大型bash 编程项目，还实现了完整自动构建系统的很大一部分。

为什么选择 bash？

Bash 是 Gentoo Linux ebuild 系统的基本组件。选择它做为 ebuild的主要语言有几个原因。首先，其语法不复杂，并且为人们所熟悉，这特别适合于调用外部程序。自动构建系统是自动调用外部程序的“胶合代码”，而bash 非常适合于这种类型的应用。第二，Bash 对函数的支持允许 ebuild系统使用模块化、易于理解的代码。第三，ebuild 系统利用了 bash对环境变量的支持，允许包维护人员和开发人员在运行时对其进行方便的在线配置。

构建过程回顾

在讨论 ebuild系统之前，让我们回顾一下编译和安装包都牵涉些什么。例如，让我们看一下"sed" 包，这个作为所有 Linux 版本一部分的标准 GNU文本流编辑实用程序。首先，下载源代码 tar 压缩包(sed-3.02.tar.gz)（请参阅参考资料）。我们将把这个档案存储在/usr/src/distfiles 中，将使用环境变量 "$DISTDIR"来引用该目录。"$DISTDIR" 是所有原始源代码 tar压缩包所在的目录，它是一个大型源代码库。

下一步是创建名为 "work"的临时目录，该目录存放已经解压的源代码。以后将使用 "$WORKDIR"环境变量引用该目录。要做到这点，进入有写权限的目录，然后输入：

将 sed 解压缩到临时目录

$ mkdir work
$ cd work
$ tar xzf /usr/src/distfiles/sed-3.02.tar.gz

然后，解压缩 tar 压缩包，创建一个包含所有源代码、名为 sed-3.02的目录。以后将使用环境变量 "$SRCDIR" 引用 sed-3.02目录。要编译程序，输入：

将 sed 解压缩到临时目录

$ cd sed-3.02
$ ./configure --prefix=/usr
（autoconf 生成适当的 make 文件，这要花一些时间）
$ make
(从源代码编译包，也要花一点时间）

因为在本文中只讲述解包和编译步骤，所以将略过 "make install"步骤。如果要编写 bash脚本来执行所有这些步骤，则代码可能类似于：

要执行解包／编译过程的样本 bash 脚本

#!/usr/bin/env bash
if [ -d work ]
then 
# remove old work directory if it exists 
    rm -rf work
fi
mkdir work
cd work
tar xzf /usr/src/distfiles/sed-3.02.tar.gz
cd sed-3.02
./configure --prefix=/usr
make

使代码通用

虽然可以使用这个自动编译脚本，但它不是很灵活。基本上，bash脚本只包含在命令行输入的所有命令列表。虽然可以使用这种解决方案，但是，最好做一个只通过更改几行就可以快速解包和编译任何包的适用脚本。这样，包维护人员将新包添加到发行版所需的工作就大为减少。让我们先尝试一下使用许多不同的环境变量来完成，使构建脚本更加适用：

新的、更通用的脚本

#!/usr/bin/env bash
# P is the package name
P=sed-3.02
# A is the archive name
A=${P}.tar.gz
export ORIGDIR=`pwd`
export WORKDIR=${ORIGDIR}/work
export SRCDIR=${WORKDIR}/${P}
if [ -z "$DISTDIR" ]
then 
    # set DISTDIR to /usr/src/distfiles if not already set
    DISTDIR=/usr/src/distfiles
fi
export DISTDIR
if [ -d ${WORKDIR} ]
then    
    # remove old work directory if it exists 
    rm -rf ${WORKDIR}
fi
mkdir ${WORKDIR}
cd ${WORKDIR}
tar xzf ${DISTDIR}/${A}
cd ${SRCDIR}
./configure --prefix=/usr
make

已经向代码中添加了很多环境变量，但是，它基本上还是执行同一功能。但是，如果现在要要编译任何标准的GNU 基于 autoconf 的源代码 tar压缩包，只需简单地将该文件复制到一个新文件（用合适的名称来反映它所编译的新包名），然后将"$A" 和 "$P"的值更改成新值即可。所有其它环境变量都自动调整成正确设置，并且脚本按预想工作。虽然这很方便，但是代码还有改进余地。这段代码比我们开始创建的"transcript"脚本要长很多。既然任何编程项目的目标之一是减少用户复杂度，所以最好大幅度缩短代码，或者至少更好地组织代码。可以用一个巧妙的方法来做到这点-- 将代码拆成两个单独文件。将该文件存为 "sed-3.02.ebuild"：

sed-3.02.ebuild

#the sed ebuild file -- very simple!
P=sed-3.02
A=${P}.tar.gz

第一个文件不重要，只包含那些必须在每个包中配置的环境变量。下面是第二个文件，它包含操作的主要部分。将它存为"ebuild"，并使它成为可执行文件：

ebuild 脚本

#!/usr/bin/env bash
if [ $# -ne 1 ]
then 
    echo "one argument expected."
    exit 1
fi
if [ -e "$1" ]
then 
    source $1
else
    echo "ebuild file $1 not found."
    exit 1
fi
export ORIGDIR=`pwd`
export WORKDIR=${ORIGDIR}/work
export SRCDIR=${WORKDIR}/${P}
if [ -z "$DISTDIR" ]
then 
    # set DISTDIR to /usr/src/distfiles if not already set
    DISTDIR=/usr/src/distfiles
fi
export DISTDIR
if [ -d ${WORKDIR} ]
then    
    # remove old work directory if it exists 
    rm -rf ${WORKDIR}
fi
mkdir ${WORKDIR}
cd ${WORKDIR}
tar xzf ${DISTDIR}/${A}
cd ${SRCDIR}
./configure --prefix=/usr
make

既然已经将构建系统拆成两个文件，我敢打赌，您一定在想它的工作原理。基本上，要编译sed，输入：

$ ./ebuild sed-3.02.ebuild

当执行 "ebuild" 时，它首先试图 "source" 变量"$1"。这是什么意思？还记得前一篇文章所讲的吗："$1" 是第一个命令行自变量 -- 在这里，是"sed-3.02.ebuild"。在 bash 中，"source" 命令从文件中读入 bash语句，然后执行它们，就好象它们直接出现在 "source"命令所在的文件中一样。因此，"source ${1}" 导致 "ebuild" 脚本执行在"sed-3.02.ebuild" 中定义 "$P" 和 "$A"的命令。这种设计更改确实方便，因为如果要编译另一个程序，而不是sed，可以简单地创建一个新的 .ebuild 文件，然后将其作为自变量传递给"ebuild" 脚本。通过这种方式，.ebuild 文件最终非常简单，而将 ebuild系统复杂的操作部分存在一处，即 "ebuild"脚本中。通过这种方式，只需编辑 "ebuild" 脚本就可以升级或增强 ebuild系统，同时将实现细节保留在 ebuild 文件之外。这里有一个 gzip 的样本ebuild 文件：

gzip-1.2.4a.ebuild

#another really simple ebuild script!
P=gzip-1.2.4a
A=${P}.tar.gz

添加功能性

好，我们正在取得进展。但是，我还想添加某些额外功能性。我希望 ebuild脚本再接受一个命令行自变量："compile"、"unpack" 或"all"。这个命令行自变量告诉 ebuild脚本要执行构建过程的哪一步。通过这种方式，可以告诉 ebuild解包档案，但不进行编译（以便在开始编译之前查看源代码档案）。要做到这点，将添加一条case 语句，该语句将测试"$2"，然后根据其值执行不同操作。代码如下：

ebuild，修定本 2

#!/usr/bin/env bash
if [ $# -ne 2 ]
then 
    echo "Please specify two args - .ebuild file and unpack, compile or all"
    exit 1
fi
if [ -z "$DISTDIR" ]
then 
    # set DISTDIR to /usr/src/distfiles if not already set
    DISTDIR=/usr/src/distfiles
fi
export DISTDIR
ebuild_unpack() {
    #make sure we're in the right directory 
    cd ${ORIGDIR}
    
    if [ -d ${WORKDIR} ]
    then    
        rm -rf ${WORKDIR}
    fi
    mkdir ${WORKDIR}
    cd ${WORKDIR}
    if [ ! -e ${DISTDIR}/${A} ]
    then
        echo "${DISTDIR}/${A} does not exist.  Please download first."
        exit 1
    fi    
    tar xzf ${DISTDIR}/${A}
    echo "Unpacked ${DISTDIR}/${A}."
    #source is now correctly unpacked
}
ebuild_compile() {
    
    #make sure we're in the right directory
    cd ${SRCDIR}
    if [ ! -d "${SRCDIR}" ]
    then
        echo "${SRCDIR} does not exist -- please unpack first."
        exit 1
        fi
    ./configure --prefix=/usr
    make     
}
export ORIGDIR=`pwd`
export WORKDIR=${ORIGDIR}/work
if [ -e "$1" ]
then 
    source $1
else
    echo "Ebuild file $1 not found."
    exit 1
fi
export SRCDIR=${WORKDIR}/${P}
case "${2}" in
    unpack)
        ebuild_unpack
        ;;
    compile)
        ebuild_compile
        ;;
    all)
        ebuild_unpack
        ebuild_compile
        ;;
    *)
        echo "Please specify unpack, compile or all as the second arg"
        exit 1
        ;;
esac

已经做了很多改动，下面来回顾一下。首先，将编译和解包步骤放入各自的函数中，其函数名分别为ebuild_compile() 和ebuild_unpack()。这是个好的步骤，因为代码正变得越来越复杂，而新函数提供了一定的模块性，使代码更有条理。在每个函数的第一行，显式"cd"到想要的目录，因为，随着代码变得越来越模块化而不是线形化，出现疏忽而在错误的当前工作目录中执行函数的可能性也变大。"cd"命令显式地使我们处于正确的位置，并防止以后出现错误 -这是重要的步骤，特别是在函数中删除文件时更是如此。

另外，还在 ebuild_compile()函数的开始处添加了一个有用的检查。现在，它检查以确保 "$SRCDIR"存在，如果不存在，则打印一条告诉用户首先解包档案然后退出的错误消息。如果愿意，可以改变这种行为，以便在"$SRCDIR" 不存在的情况下，ebuild脚本将自动解包源代码档案。可以用以下代码替换 ebuild_compile()来做到这点：

ebuild_compile() 上的新代码

ebuild_compile() {
    #make sure we're in the right directory  
    if [ ! -d "${SRCDIR}" ]
    then
        ebuild_unpack
        fi
    cd ${SRCDIR}
    ./configure --prefix=/usr
    make     
}

ebuild 脚本第二版中最明显的改动之一就是代码末尾新的 case语句。这条 case语句只是检查第二个命令行自变量，然后根据其值执行正确操作。如果现在输入：

$ ebuild sed-3.02.ebuild

就会得到一条错误消息。现在需要告诉 ebuild 做什么，如下所示：

$ ebuild sed-3.02.ebuild unpack

或

$ ebuild sed-3.02.ebuild compile

或

$ ebuild sed-3.02.ebuild all

如果提供上面所列之外的第二个命令行自变量，将得到一条错误消息（*子句），然后，程序退出。

使代码模块化

既然代码很高级并且实用，您可能很想创建几个更高级的 ebuild脚本，以解包和编译所喜爱的程序。如果这样做，迟早会遇到一些不使用autoconf ("./configure")的源代码，或者可能遇到其它使用非标准编译过程的脚本。需要再对 ebuild系统做一些改动，以适应这些程序。但是在做之前，最好先想一下如何完成。

将 "./configure --prefix=/usr; make"硬编码到编译阶段的妙处之一是：大多数时候，它可以正确工作。但是，还必须使ebuild 系统适应那些不使用 autoconf 或正常 make文件的源代码。要解决这个问题，建议 ebuild脚本缺省执行以下操作：

如果在 "${SRCDIR}" 中有一个配置脚本，则按如下执行它：
./configure --prefix=/usr
否则，跳过这步。
执行以下命令：
make

既然 ebuild 只在 configure实际存在时才运行它，现在可以自动地适应那些不使用 autoconf 但有标准make 文件的程序。但是，在简单的 "make"对某些源代码无效时该怎么办？需要一些处理这些情况的特定代码来覆盖合理的缺省值。要做到这一点，将把ebuild_compile()函数转换成两个函数。第一个函数（可将其当成“父”函数）的名称仍是ebuild_compile()。但是，将有一个名为 user_compile()的新函数，该函数只包含合理的缺省操作：

拆成两个函数的 ebuild_compile()

user_compile() {
    #we're already in ${SRCDIR}
    if [ -e configure ]
    then
        #run configure script if it exists
        ./configure --prefix=/usr
    fi
    #run make
    make
}          
ebuild_compile() {
    if [ ! -d "${SRCDIR}" ]
    then
        echo "${SRCDIR} does not exist -- please unpack first."
        exit 1
    fi
    #make sure we're in the right directory  
    cd ${SRCDIR}
    user_compile
}

现在这样做的原因可能还不是很明显，但是，再忍耐一下。虽然这段代码与ebuild 前一版的工作方式几乎相同，但是现在可以做一些以前无法做的 --可以在 sed-3.02.ebuild 中覆盖 user_compile()。因此，如果缺省的user_compile() 不满足要求，可以在 .ebuild文件中定义一个新的，使其包含编译包所必需的命令。例如，这里有一个e2fsprogs-1.18 的 ebuild 文件，它需要一个略有不同的 "./configure"行：

e2fsprogs-1.18.ebuild

#this ebuild file overrides the default user_compile()
P=e2fsprogs-1.18
A=${P}.tar.gz
 
user_compile() {
       ./configure --enable-elf-shlibs
       make
}

现在，将完全按照我们希望的方式编译e2fsprogs。但是，对于大多数包来说，可以省略 .ebuild文件中的任何定制 user_compile() 函数，而使用缺省的 user_compile()函数。

ebuild 脚本又怎样知道要使用哪个 user_compile()函数呢？实际上，这很简单。ebuild 脚本中，在执行e2fsprogs-1.18.ebuild 文件之前定义缺省 user_compile() 函数。如果在e2fsprogs-1.18.ebuild 中有一个user_compile()，则它覆盖前面定义的缺省版本。如果没有，则使用缺省user_compile() 函数。

这是好工具，我们已经添加了很多灵活性，而无需任何复杂代码（如果不需要的话）。在这里就不讲了，但是，还应该对ebuild_unpack()做类似修改，以便用户可以覆盖缺省解包过程。如果要做任何修补，或者文件包含在多个档案中，则这非常方便。还有个好主意是修改解包代码，以便它可以缺省识别由bzip2 压缩的 tar 压缩包。

配置文件

目前为止，已经讲了很多不方便的 bash技术，现在再讲一个。通常，如果程序在 /etc中有一个配置文件是很方便的。幸运的是，用 bash做到这点很容易。只需创建以下文件，然后并其存为 /etc/ebuild.conf即可：

/ect/ebuild.conf

# /etc/ebuild.conf: set system-wide ebuild options in this file
# MAKEOPTS are options passed to make
MAKEOPTS="-j2"

在该例中，只包括了一个配置选项，但是，您可以包括更多。bash的一个妙处是：通过执行该文件，就可以对它进行语法分析。在大多数解释型语言中，都可以使用这个设计窍门。执行/etc/ebuild.conf 之后，在 ebuild 脚本中定义"$MAKEOPTS"。将利用它允许用户向 make传递选项。通常，将使用该选项来允许用户告诉 ebuild 执行并行 make。

什么是并行 make？

为了提高多处理器系统的编译速度，make支持并行编译程序。这意味着，make同时编译用户指定数目的源文件（以便使用多处理器系统中的额外处理器），而不是一次只编译一个源文件。通过向make 传递 -j # 选项来启用并行 make，如下所示：

make -j4 MAKE="make -j4"

这行代码指示 make 同时编译四个程序。 MAKE="make -j4" 自变量告诉 make，向其启动的任何子 make 进程传递 -j4 选项。

这里是 ebuild 程序的最终版本：

ebuild，最终版本

#!/usr/bin/env bash
if [ $# -ne 2 ]
then 
    echo "Please specify ebuild file and unpack, compile or all"
    exit 1
fi
source /etc/ebuild.conf
if [ -z "$DISTDIR" ]
then 
    # set DISTDIR to /usr/src/distfiles if not already set
    DISTDIR=/usr/src/distfiles
fi
export DISTDIR
ebuild_unpack() {
    #make sure we're in the right directory 
    cd ${ORIGDIR}
    
    if [ -d ${WORKDIR} ]
    then    
        rm -rf ${WORKDIR}
    fi
    mkdir ${WORKDIR}
    cd ${WORKDIR}
    if [ ! -e ${DISTDIR}/${A} ]
    then
        echo "${DISTDIR}/${A} does not exist.  Please download first."
        exit 1
    fi
    tar xzf ${DISTDIR}/${A}
    echo "Unpacked ${DISTDIR}/${A}."
    #source is now correctly unpacked
}
user_compile() {
    #we're already in ${SRCDIR}
    if [ -e configure ]
    then
        #run configure script if it exists
        ./configure --prefix=/usr
    fi
        #run make
        make $MAKEOPTS MAKE="make $MAKEOPTS"  
} 
ebuild_compile() {
    if [ ! -d "${SRCDIR}" ]
    then
        echo "${SRCDIR} does not exist -- please unpack first."
        exit 1
    fi
        #make sure we're in the right directory  
    cd ${SRCDIR}
    user_compile
}
export ORIGDIR=`pwd`
export WORKDIR=${ORIGDIR}/work
if [ -e "$1" ]
then 
    source $1
else
    echo "Ebuild file $1 not found."
    exit 1
fi
export SRCDIR=${WORKDIR}/${P}
case "${2}" in
    unpack)
        ebuild_unpack
        ;;
    compile)
        ebuild_compile
        ;;
    all)
        ebuild_unpack
        ebuild_compile
        ;;
    *)
        echo "Please specify unpack, compile or all as the second arg"
        exit 1
        ;;
esac

请注意，在文件的开始部分执行/etc/ebuild.conf。另外，还要注意，在缺省 user_compile() 函数中使用"$MAKEOPTS"。您可能在想，这管用吗 - 毕竟，在执行实际上事先定义"$MAKEOPTS" 的 /etc/ebuild.conf 之前，我们引用了"$MAKEOPTS"。对我们来说幸运的是，这没有问题，因为变量扩展只在执行user_compile() 时才发生。在执行 user_compile() 时，已经执行了/etc/ebuild.conf，并且 "$MAKEOPTS" 也被设置成正确的值。

结束语

本文已经讲述了很多 bash 编程技术，但是，只触及到 bash能力的一些皮毛。例如，Gentoo Linux ebuild产品不仅自动解包和编译每个包，还可以：

如果在 "$DISTDIR" 没找到源代码，则自动下载
通过使用 MD5 消息摘要，验证源代码没有受到破坏
如果请求，则将编译过的应用程序安装到正在使用的文件系统，并记录所有安装的文件，以便日后可以方便地将包卸载。
如果请求，则将编译过的应用程序打包成 tar压缩包（以您希望的形式压缩），以便以后可以在另一台计算机上，或者在基于CD 的安装过程中（如果在构建发行版 CD）安装。

另外，ebuild系统产品还有几个全局配置选项，允许用户指定选项，例如在编译过程中使用什么优化标志，在那些支持它的包中是否应该缺省启用可选的包支持（例如GNOME 和 slang）。

显然，bash可以实现的功能远比本系列文章中所触及的要多。关于这个不可思议的工具，希望您已经学到了很多，并鼓舞您使用bash 来加快和增强开发项目。