一个基于Bash的轻量级构建系统的设计与实现


第40卷 第11A 期 2013年11月 计 算 机 科 学 Computer Science Vol.40No.11A Nov 2013 本文受国家自然科学基金(60972016 ),湖北省杰出青年基金(2009CDA150)资助。 白 云(1977-),男,博士后,主要研究方向为无线通信系统、网络建模等;喻 莉(1970-),女,教授,博士生导师,主要研究方向为计算机网络 与多媒体通信;谢长生(1957-),男,教授,博士生导师,主要研究方向为计算机新型存储体系结构、多媒体信息存储。 一个基于Bash的轻量级构建系统的设计与实现 白 云 喻 莉 谢长生 (华中科技大学计算机系 武汉光电国家实验室 武汉430074)   摘 要 基于在 Linux各发行版本中广泛支持的Bash脚本语言,设计并实现了一个轻量级构建系统,用以管理构建 过程中的各种复杂性要素,从而在多个不同硬件平台上实现嵌入式Linux图形界面操作系统的深度定制。通过该系 统的独特设计和简洁实现,全新的轻量级构建系统具有对环境依赖度小、深度定制更为便捷、持续开发更为灵活高效 等特点。 关键词 嵌入式 Linux,构建系统,交叉编译 中图法分类号 TN911.7   文献标识码 A   Design and Implemetation of a Lightweight Building Framework Based on Bash BAI Yun YU Li XIE Chang-sheng (Wuhan National Laboratory for Optoelectronics,Huazhong Science & Technology University,Wuhan 430074,China)   Abstract A lightweight building framework was designed and implemented based on Bash script language widely sup- ported in various distribution of Linux,for the purpose of managing the complexity factors in building operation system, thus deeply customizing embedded Linux operation system with graphics user interface upon various hardware plat- form.Based on these unique design and simplification,the resulting system can be less environmental dependent,more efficient for continuous development. Keywords Embedded Linux,Building framework,Cross compile   1 概述 随着移动计 算(Mobile Computing)的 普 及,嵌 入 式 系 统 (Embedded System)已经发生了深刻的变化。嵌入式处理器 的性能已经迈过 多 媒 体 PC 的 门 槛,使 得 嵌 入 式 系 统 也 可 以 具有现代的高级图形交互界面、网络文件系统、高性 能 音 频、 视频处理等功能,与 PC 机 越 来 越 相 似。这类新型的嵌入式 系统被称为 SBC(Single Board Computer,单板电脑)[1]。 在SBC硬件平台上,可以基于 Linux操作系统内核构建 一个带有图形界面的操作系统,同时根据具体应用的需求,配 套定制应用软件的开发和运行平台。典型的软件运行平台基 本内容包括:图形用户操作界面、鼠标键盘或触摸屏的支持、 硬件即插即用、中文显示与输入、TTS语音播报引擎、有线和 无线网络的访问管理以及基于 Qt的应用软件开发和运行环 境等内容。 与以往操作系统被列为整体系统的一个采购项的做法有 所不同,自主构建的操作系统中包括内核在内的绝大多数软 件包均可以进行深度定制。定制操作系统不仅可以降低采购 成本,还可以更为灵活高效地对已有功能进行扩展,提高内在 品牌价值。例如,开机时显示产品LOGO、基于硬件产品标识 的加密,或是当用户插入 USB 上网卡时自动拨号联网等,这 些定制特性在自主操作系统中所需的开发量更小,同时设计 的自由度更大。 以 Ubuntu、Debian为 代 表,许 多 PC 上 的 Linux操 作 系 统的发行版本都通过网站的形式提供了详细构建方法,因此 理论上任何人都可以利用这些知识,从零开始构建一个操作 系统。但实际上,搭建一个操作系统的复杂度仍然是比较高 的。这是因为软件环境是由许多相互依赖的软件包构成的, 当软件包的数量增加到一定级别时,这种依赖关系会变得非 常复杂;其次,深度定制时将会针对不同的需求对个别软件包 进行合理的修改,而这种配置操作有时会改变依赖关系,使其 更加复杂;另外,为了完成一些特定的功能,可能修改 部 分 源 码,在修改过程中可能对源码进行反复调试,大型的构建系统 中这种调试比较难以实现。 因此,软件平台的构建工作本身就需要一套软件工具来 辅助 完 成,本文称这一工具为构建系统(Building Frame- work)。 在总结现有构建系统设计要点的基础上,本文 设 计 并 实 现了一个轻量级的构建系统。该系统重点针对嵌入式系统中 的实际应用需要,面向快速定制和持续集成,进行了创新性的 设计,更加简洁高效和易于掌握。本 文 的 工 作 已 经 在 TI的 OMAP3530和 Freescale的i.MX.536 两 款 ARM 处 理 器 平 台上进行了验证,分别搭建了基于 Qt-QWS和基于 X11/Gtk 的多个不同规格的定制系统。 ·8· 2 现有系统 2.1 已有系统 OpenEmbedded[3]和lfs[4]是应用较为广泛的、面 向 嵌 入 式系统的大型构建系统。 其中,OpenEmbedded是一种开源的面向嵌入式的构建 系统,它基于bitbaker脚本解释器,可以对绝大多数开源软件 包进行构建。基于 OpenEmbedded开发的嵌入式操作系统包 括 ngstrm[5]、Openmoko和 SlugOS等,这些操作系统基本 具备现代图形界面操作系统所必须的大部分功能,区别只是 运行在嵌入式平台之上而已。 软件包之间的“依赖性”非常适合用网站的形式来表现, lfs就是其中之一。lfs是linux from scratch的简称,即“从零 开始 构 建 Linux”。lfs的 各 种 版 本 包 括 clfs (cross-compile lfs)、blfs(beyond lfs)以及cblfs、alfs等等。其中cblfs就是关 注于建立图形化界面的嵌入式Linux操作系统的,lfs同时以 网站、源码和书籍等形式提供构建系统。 Freescale公司所使用的构建系统ltib就是基于lfs的,而 TI公司的演示系统则使用基于 OpenEmbedded 构 建 的 ngstrm。 除此之外,在非嵌入式平台上的各种主流Linux操 作 系 统也正在向嵌入式平台上迁移。例 如 各 种 基 于 Linux的 PC 机操作系统包括 Ubuntu、Mint、FreeBSD 或 Debian等。这 些 系统本身都是一个构建系统的产物,在对应的网站上,可以查 询到每一个软件包的构建方法及其相关的软件包名称。 2.2 构建系统的定义 即使是构建小型的实用系统,构建系统管理的软件包数 量也通常能达到100个左右,对于较为完善的构建系统,这个 数字可能上升到几千甚至上万,这时仅仅考虑软件包之间的 依赖关系就已经非常复杂了;一些大型的构建系统的构建时 间可能达到8小时甚至几天,因此对于系统的稳定性和可靠 性也有较高要求。 本文将构建系统(build framework)定义为对大量的源码 包(source package)进行 编 译、管理和部署的系统,这 3 部 分 功能分别包括: ·可配置的选择性编译。对每个源码 包,基 于 一 定 的 预 定义规则进行配置和定制,并用相应的编译器进行编译。 ·源码包管理。首先,管理源 码 包 的 内 容;其 次,管 理 编 译生成的内容,包括目依赖关系,从而自动组织源码包编译的 先后顺序标码(Release或 Debug版本)、说明文档、头文件、动 态或静态链接库、配置文件、资源文件等,针对总体需 求 进 行 选择。 ·部署。即对编译生成的内容进行选择性的发布,并 设 计合理的目录结构,添加一定的系统配置文件和正常运行所 必须的脚本。 2.3 本文系统的特点 现有的构建系统大多是大而全的半商业系统,会 带 来 下 列问题:首先,默认只能针对固定的几款硬件平台,硬 件 选 型 受限;其次,系统的复杂度较高,不利于灵活高效地进行扩展; 另外,需要额外的脚本解释工具支持,不具有更为通用的扩展 性;最后,系统编译耗时较长,不适应于嵌入式平台的特点。 为了对自有产品实现完全的掌控和高效的定制,本 文 设 计了一个全新的构建系统,包含如下的设计目标: (1)易于学习和使用。即除了编译软件包所必须的知识 以外,所需要学习的额外内容较少,这要求系统的复杂度较 低。 (2)易于扩充和裁剪。必须假定构建系统是不断发展的, 因此必须便于针对新的需求进行修改。 (3)系统在引入新的软件包进行编译和配置时,必须非常 便于调试。 (4)应该有阶段性的输出目标,可以通过产品名称来标识 一个阶段成果。 (5)在构建交叉编译环境时,充分利用宿主机已有的丰富 功能。 基于上述设计要点,选择基于 Bash实现该构建系统。这 是因为:首先,Bash是最为广泛支持的脚本解释器;其 次,解 释型语言比编译型语言有更好的需求变动适应性;最后,Bash 本身就是linux操作系统的命令行运行环境,这 样 在 搭 建 交 叉编译环境的时候,可以充分利用宿主机的功能,减少一些不 必要的工作,对于一些有着特殊构建方法的软件包,也有足够 的可适应性。 3 基于 BASH 的构建系统 3.1 构建方法共性机制 虽然构建方法是一个构建系统中的重要组成部分,但 是 对每一个软件包而言,其构建方法是相对固定的,大量参考文 献[4-6]详尽地进 行 了 描 述。因 此,本文不讨论具体的构建方 法,仅描述一般的共性机制。 3.1.1 交叉编译 面向嵌入式的构建系统常常需要进行交叉编译(Cross Compile)。交叉编译也是一种编译(compile)形 式,即 从 源 代 码(source code)编译生成目标码(object code),但是在交叉编 译的情况下,编译器与目标码所处的“运行环境”可能部分或 者完全不相同。 参照 GNU 的命名 规 范,“运 行 环 境”可以被定义为一个 唯一的字符串标识,即将每一种要素按一定顺序描述出来,例 如:arm-none-linux-gnueabi。在交叉编译中有3 种 “运 行 环 境”的概 念,分 别 是:编 译 机 (build)、主 机 (host)和 目 标 机 (target),build,host和target 3个参数合起来被称为交叉编 译三元组(triplet)。 3.1.2 GNU Automake 对于一个源码包而言,需要一套工具对其中的源代码进 行管理 和 组 织 编 译,这种工具可以统称为编译系统(build system)[2],较为熟知的编译系统包括gnu make、ant、CMake 等等。 在 Linux平台上的绝大多数软件包使用传统的 makefile 模式进行编译。makefile遵 循 GUNMakefile规 范,使 用 时 最 为灵活,但缺点是学习周期较长,同时生成的 makefile与软件 环境密切相关,不支持 跨 平 台。使 用 makefile进 行 软 件 包 编 译一般规律是指定一个目标(target),并 调 用 GNU 的 make 命令进行编译。 对大型项目编写 makefile,即使是熟练的工程人员,也是 一项挑战。另外,在一个操作系统中编写的 makefile,放到另 外一个操作系统可能也必须进行大量的修改。为弥补 make- file的这些 缺 点,GNU 早 在 20 世 纪 90 年 代 就 开 始 了 auto- ·9· make框架的设计,目前这一框架已经被广泛使用,面 向 交 叉 编译的支持也越来越完善。 简而 言 之,automake 框 架 包 含 了 automake、autoconf、 libtool、M4、Perl等多个软件包,其最主要的作用就是根据非 常精简的预定 义 脚 本,生 成 一 个configure可 执 行 脚 本,提 供 项目可选的配置属性,并通过configure脚本自动生成 make- file。同时,由于软件包之间往往不是孤立的,如 何 在 编 译 时 确定所依赖的其它软件包的安装位置?较为通用的方法是利 pkg-config命令,该命 令 也 是 GNU Automake规 范 中 的 内 容 之一。 少数例外的软件包不使用 Automake体 系,比 如 著 名 的 QT 软件包,其使用了自制的 qmake生 成 makefile,一 些 基 于 ibus的输入法使用了CMake来管理源码资源,还有一些使用 PHP、TCL、Python等脚本解释器进行辅助编译。 3.1.3 内存文件系统 绝大多数的源码包具有一些相同的特点,比如 单 个 文 件 不大,但小文件的数量特别多,加起来的总量又一般不会超过 几百 MB,一旦编译完成,这些源代码文件一般不再需要。 这些特点非常适合使用内存文件系统,而不是 一 般 的 磁 盘文件系统。因此,本文一般会选择使用linux tmpfs内存文 件系统作为可挥发(volatile)内容的暂存位置。 3.1.4 失败退出与日志记录 编译一个源码包时,一般情况下如果任何一个步骤异常, 后续步骤就失去了继续下去的意义,必须终止构建。同时,需 要快速定位故障点。因此,系统实现的通用机制包括: ·失败退出。执行传入的 bash命令,等待结束,获 得 进 程结束后的返回值,在发现进程失败时退出。 ·暂存日志和告警。由于大多数软件包在编译时会输出 大量的信息,这些信息在构建失败时非常有助于定位问题,但 正常情况下,这些调试输出不仅拖慢构建进程,同时也会使正 常的进度报告信息被完全淹没。因此利用linux的重定向功 能,将stdio和stderr上的输出分别保存到内存文件系统的 log和 warn文件,并在成功编译一个软件包后删除这两个文 件。 3.1.5 源码解压与补丁 软件包是以压缩包的形式呈现的,这些压缩包 的 压 缩 算 法不尽相同。本文假 定 压 缩 包 使 用tar压 制,压 缩 算 法 通 过 后缀名自动识别,可以是gz、bz2或者xz。源码解压后生成一 个单一目录,其目录名与压缩包的名称(去除.tar.xx后缀后) 一致。这一假定符合绝大多数源码包的实际情况,对 少 数 特 殊命名的源码包,可以人为地进行调整。 源码包常常需要在一个基础版本上进行微调,即 所 谓 的 打补丁(patch)操作。补丁实际上也是源码的一种,其重要性 不亚于源码本身。本系统假定补丁是使用diff工 具 生 成 的, 打补丁操作通过patch工具来完成。 源码解压、打补丁这一过程被包装为prepare操作,即将 源码包解压到指定的内存文件系统目录,并对解压后的源码 打补丁。 3.1.6 交叉编译的一般步骤 在上文描述的实现基础之上,设计实现了build_native脚 本一步完成解压、补丁、配置、编译、安装的全 部 操 作,并 可 进 行少量的微调,包括: ·更换源码包名称,用于更换同一源码的不同版本; ·更换源码包的编译配置命令; ·不要prepare,即假定源码包已经解压完成; ·临时编译指 定 的target,这在编译一个较大源码包中 特定子库时非常实用; ·指定在源码目录平级的临时目录中还是在源码目录内 编译。前者是一些源 码 包,比 如linux内 核、glibc等,为 了 避 免污染源码目录,而建议采用的编译方式。但如果已 经 完 成 部分编译,仅需要再编译部分源码包时,后者要快得多。 ·是否通过 make check编译运行系统测试以验证可用 性。在大多数交叉编译的环境中,目标码在编译机中无法执 行,因此没有办法进行系统测试。 3.2 依赖管理 软件包之间存在着依赖关系,比如图1所示 的 是 准 备 构 建 X11所需要的最为基础的几个软件包之间的依赖关系示 意图。在实际情况中,软件包的依赖关系远比该图复杂。 图1 部分 X11软件包之间的依赖关系图 本文设计的构建系统依赖关系管理机制如下: 首先,将整个构建进程定义为若干任务(TASK),每个任 务对应为编译一个具体的软件包(PACKAGE),为方便调试, 使用一个中文字符串作为任务的唯一标识。 其次,将 TASK 分 为 build和compile两 个 阶 段,分 别 对 应函 数 名 为 build_taskname()和 compile_taskname()的 BASH 函数。只有在compile_xxx()中才会真正开始编译一 个软件包,同时规定compile_taskname()只能由相应的 build _taskname()调用在prep阶段。对于本软件包所依赖的每一 个软件包,依次调用相应 的 build_xxx()函 数,然 后 再 使 用 工 具函数run_task启动自身的构建。例如,编译处理字体文件 的freetype软件包时,需要用到处理压缩算法的zlib软件包, 其prep阶段代码如图2所示。 build_libfreetype() {   build_libz   run_task"构建$FREETYPEFILE""compile_libfreetype" } 图2 交叉编译的标准步骤 接下来,run_task在 启 动 相 应 的 compile_taskname()函 数以前,会试图在一个内存文件中加入一行该任务的标识,这 一内存文件在启动构建系统的时候会被清空。run_task脚本 如果发现该标识已经存在,就会直接返回,而不会启动编译工 作。 同时,为保证多次调试时不需要重复编译已经调试完成 的软件包,complie_taskname在启动前会首先检查缓存,如果 存在同名的压缩包,说明已经成功编译过,将不再重新编译。 这一设计保证了:1)所有的任务只会运行一遍;2)依赖的 ·01· 任务一定先于本任务自身运行。在这两点的保障下,构 建 系 统会自动安排编译执行顺序。 不过,在这样 的 设 计 下,依赖环路仍然是一个问题。首 先,从逻辑上分析,依赖环路是一种错误,必须与实际 中 多 次 构建同一个软件包的情况区别开。例如,在搭建交叉 编 译 环 境时,首先需要编译基础的gcc软件包,使其成为一个 C 语言 编译器,接着编译glibc(或uclibc等其他等价实现)实现标准 C运行时库,然后再次 编 译 gcc,使 其 支 持 C+ + 编 译。需 要 注意 的 是,这样两次编译时使用的配置参数是不同的,com- pile_xxx()脚本中的内容也必然不同,因此应该视为不同的构 建任务。因此,无论软件包之间的依赖关系多么复杂,其关系 图中都不可能出现环路,环路的存在一定是由于构建方法存 在着错误,应该在构建系统启动之初检测出来。 本系统只进行 环 路 检 测。环路检测可通过设置使run_ task不调用实际的编译操作compile_xxx,再重复一次整体的 构建,这样的“伪”构建应该很快完成。在存在回路时,“伪”构 建会出现死循环,在一定时间后(比如10秒钟后)伪构建没有 结束,说明存在依赖关系环路,即 可 中 止 运 行。这 时,run_ task负责写入的任务标识文件列表中最后一个任务标识,就 是出现依赖环路的故障点。 大多数大型构建系统是通过配置文件管理依赖关系的, 而本文中的prep阶段实际上完成了相同的工作。在 开 发 的 阶段,将依赖关系配置和实际编译的代码放在一起更方便调 试;在产品 定 型 后,也可以将这些部分分别保存到不同的 BASH 脚本中去。省略专门的配置文件也是为了减少需求变 更时的修改点。 3.3 产品定义 现实中构建系统的开发是没有终点的,因为操 作 系 统 会 针对新特性不断完善和升级。但反映构建系统的阶段性成果 也是一个必需的要求,这一点可以通过产品发布的形式完成。 与产品发布相关的概念大致有如下几个,在本构建系统中均 体现为不同的 BASH 环境变量: ·产品(PRODUCT)。不同的产品名称可能采用不同的 硬件 体 系 结 构、不 同 的 Linux 内 核、不 同 的 软 件 包,因 此 PRODUCT 决定了整个构建系统需要进行什么样的构建操 作。 ·配置(CONFIG)。希望目标系统具有什么特性,例如: X11窗 口 系 统 (CONFIG_X11)、需 要 音 频 处 理 (CONFIG_ SOUND)。构建系统会根据这些配置,选择不同的软件包组 合。 ·能力(CAPABILITY)。受 PRODUCT 选 择 的 硬 件 平 台限制,所具有的能力选项。比如具有硬件图形协处理器 (CAP_GPU),可以编译图形加速的相关功能,否则只能选择 软件实现的驱动。 ·源码包(PACKAGE)。对应一个具体的源码包,比 如 PACKAGE_XORG= xorg-server-1.12.4,包对应的属性有版 本号、编译方法、编 译 参 数、编 译 步 骤 等,均 通 过 一 个 BASH 函数实现。但一般而言,即使同一软件包的不同版本,其编译 方法也可能完全不一样,这时就必须视为不同的PACKAGE 来处理。 ·发布包(DIST)。一 个 源 码 包 (PACKAGE)可 以 对 应 多个发布包(DIST),最常见的是从同一份源码产生运行态和 开发态的两个发布包。前者仅包含可执行文件、链接 库 及 必 须的配置文件等;而后者还必须包括开发所需的头文件和构 建所需的辅助脚本等。 本构建系统仅将PRODUCT 做为可选配置变量,所有配 置均通过 BASH 函数得以体现,如图3所示。 #〉./build_all.sh fsl_ecs #〉./build_all.sh ti_ecs 图3 分别构建基于freescale和ti两款芯片的ecs产品平台 这样会分别执行construct_fsl_ecs()和construct_ti_ecs ()函数,设置相应的 PLATFORM 和 CAPABILITY 变 量,然 后根据 CONFIG 不同调用不同的BASH 函数,例如 CONFIG _X11则调用construct_x11()函数,在constrct_x11函数中再 具体地组装各个软件包,比 如 build_xorg_server()、build_ gtk2()、bulid_qt_x11()等。在前面介绍的依赖管理机制作用 下,只需要指定最主要的几个软件包即可,其它的依赖软件包 会自动执行。 软件包的选择是依赖于PRODUCT 和 CAPABILITY 变 量的(后者实际上是一组变量),而 PRODUCT 的定义实际上 包含了产品(软件范畴)和平台(硬件范畴)两重概念。比 如, 内核的编译build_kernel()会根据 PRODUCT 变量选择相应 厂商提供的源码包,可以自行决定是分别实现build_kernel_ fsl()、build_kernel_ti(),还是在一个build_kernel中通过多个 if-else来实现。考虑到不同产品中有若干功能是重叠的,本 文实际采用了后面一种方式。 3.4 发布助手 对于编译完成后安装的内容,本系统设计了4种组态: (1)CACHE。所有 文 件 被 直 接 安 装 到 $CACHEDIR 目 录,即 make install DESTDIR= $CACHEDIR。这 时 发 布 助 手将其打包为一个压缩文件,CACHE 组态的文件包含了一 个软件包可能生成的所有内容。 (2)BOOT。以u-boot和uImage等负责引导为主的生成 内容,这部分内容有可能需要通过直接io操 作 写 到 指 定 扇 区,因此单独保存到$BOOTIDR 目录。 (3)DIST,发布 态 文 件。这部分文件构成了嵌入式系统 实际运行时的根文件系统,可以直接以文件的形式存在,也可 以打包成 rpm 或 deb 格 式 的 安 装 包。 由发布助手自动从 $CACHEDIR 中 复 制 过 来,但一般会去除其中的静态库 (.a)、头文件(.h)、libtool文件(.la)、man文件(.man)及其他 帮助文件,同时对可执行文件、库文件(.so)进行strip操作以 减小发布映像的大小。 (4)SDK,开 发 态 文 件。 这部分文件由发布助手从 $CACHEDIR 中直接复制过 来,在编译其它软件包时,可 能 需要其中的头文件、静态库等内容,但实际运行时并不需要, 因此不需要发布到根文件系统中以减小容量占用。同 时, pkg-config、autoconf等交叉编译工具也被指向这个目录,有 助于避免交叉编译环境受到宿主机环境污染。 3.5 交叉编译环境污染 在交叉编译的时候,软件包可能读取编译机(build)的环 境进行配置,从而导致错误的编译结果,这种现象被称为交叉 编译环境受到污染。 这种污染的成因可能是多方面的,比如错误地读取了/ usr/include目录下的头文件,从而错误地认为目标主机具有 ·11· 某种能力,而 编 译 出 错 误 的 代 码;或 者,错 误 地 读 取 了/usr/ lib/pkgconfig目录的.pc文件,从而错误地认为目标主机有某 些软件包,从而导致运行时发生找不到动态链接库的错误;又 比如,在配置时错误地读取了/usr/share/aclocal中的文件,从 而生成了错误的configure脚本。 一般情况下,编译 机(build)具 有 比 主 机(host)更 强 的 能 力,环境污染会误导交叉编译器使用错误的编译方式,而这种 错误会一直隐藏到运行时才得以发觉,因此危害较大。 “解决交叉编译环境的污染问题”和“适当利用宿主机现 有的工具”二者之间是一个矛盾的关系。大型的构建系统自 行设计了一 套 工 具 (fakeroot、sandbox等),从根本上解决了 环境污染的问题。但这样就完全不能利用宿主机现有的功能 了,同时需要构建一个“完整而纯净的”交叉编译环境,对于某 些小型的嵌入式应用,这一工作量反而超过了构建产品本身 所需的工作量。 本文自行构建了较新版本的pkg-config、automake、auto- conf和libtool等工具,同时在SDK 目录中部署了宿主机版本 的 glib 可 执 行 文 件 (glib-compile-schema 也 是 一 个 编 译 工 具),但对其它的 工 具 包,比 如 perl语 言 环 境、phyton语 言 环 境、CMake编译工具等,由于较少涉及而忽略。 即使如此,有些软件包仍然需要在configure的时候在宿 主机和目标机环境之间切换,这时,可以采取如下3种办法临 时适应其具体需求: (1)Hide/Restore Header。将/usr/include和/usr/local/ include这些编译器预设路径临时隐藏。 (2)Hide/Restore Autoconf。将/usr/share/aclocal等 目 录临时隐藏。 (3)Hide/Restore pkgconfig。 将/usr/lib/pkgconfig 和/ usr/share/pkgconfig等目录临时隐藏。 结束语 本文设计了一个基于Bash的自制构建系统,展 示了深度定制操作系统的可能性。本文设计的构建系统具有 实现机制易于学习掌握、支持增量调试与开发方便引入新增 特性、支持按特性描述的配置项定义以支持不同硬件平台和 不同的软件特性等特点,同时基于普遍支持的bash脚本环境 具有最大的可适应性,并可按产品名称为标识输出阶段性的 研发成果。 目前,整个构建系统的实现框架已基本定型,编译方法模 块也已经初具规模,基本实现了与硬件密切结合的 QT_QWS 及 Qt_X11两类不同规格的自主定制的软件环境。未来的工 作将可以不断引入新的软件包和新的功能,同时对已有的功 能进行升级和修改,使得应用系统越来越完善。 参 考 文 献 [1] Rosli A N C,Shakaff A Y M,et al.Face reader for biometric identification using Single Board Computer and GNU/Linux[C]∥ International Conference on Robotics,Vision,Information,and Signal Processing,2007.Penang,Malaysia,2007 [2] Adams B,Schutter K D,Tromp H,et al.The Evolution of the Linux Build System[C]∥The Third International ERCIM Sym- posium on Software Evolution,2007.2007 [3] Lauer M.Building Embedded Linux Distributions with BitBake and OpenEmbedded[C]∥Proceedings of the Free and Open Source Software Developers’European Meeting(FOSDEM). Brussels,Belgium,Feb.2005 [4] Beekmans G.Linux From Scratch Version 6.2[M].onlinewebli- brary.com,2006 [5] Angstrom Web Site[OL].http://www.angstrom-distribution. org/,2012 [6] Yaghmour K,Masters J,Ben-Yossef G,e t al.构建嵌入式 LINUX 系统(第2 版)[M].Taiwan O R 公 司,译.秦 云 川 (改 编),中国电力出版社,2011 (上接第3页) 入自己最近的簇,形成大小规模不等的簇;数据转发采用簇内 单跳,簇间单跳、多跳相结合的方式,距离基站较近的特殊节 点直接与基站通信。通过降低网络内通信来减少网络能量消 耗,均衡网 络 开 销。实 验 证 明,SIAUCR 算 法 均 衡 了 网 络 能 耗,能量利用率、网络寿命要优于 LEACH、CEBRCA,同时数 据发送效率也获得较好效果。 参 考 文 献 [1] Patel H,Pandya N.Study and Review of Routing protocols for wireless sensor networks[J].International Journal of Enginee- ring,2013,2(1) [2] Norouzi A,Babamir F S,Zaim A H.A novel energy efficient routing protocol in wireless sensor networks[J].Wireless Sen- sor Network,2011,3(10):341-350 [3] Manap Z,Ali B M,Ng C K,et al.A Review on Hierarchical Routing Protocols for Wireless Sensor Networks[J].Wireless Personal Communications,2013:1-28 [4] Heinzelman W R,Chandrakasan A,Balakrishnan H.Energy-ef- ficient communication protocol for wireless microsensor net- works[C]∥Proceedings of the 33rd Annual Hawaii Internation- al Conference on System Sciences,2000.IEEE,2000,2 [5] Mhatre V,Rosenberg C.Design guidelines for wireless sensor networks:communication,clustering and aggregation[J].Ad hoc Networks,2004,2(1):45-63 [6] Kuila P,Jana P K.An energy balanced distributed clustering and routing algorithm for Wireless Sensor Networks[C]∥Parallel Distributed and Grid Computing(PDGC),2012 2nd IEEE Inter- national Conference on.IEEE,2012:220-225 [7] Ali S A,Sevgi C.Energy Load Balancing for Fixed Clustering in Wireless Sensor Networks[C]∥ New Technologies,Mobility and Security (NTMS),2012 5th International Conference on. IEEE,2012:1-5 [8] Heinzelman W B,Chandrakasan A P,Balakrishnan H.An appli- cation-specific protocol architecture for wireless microsensor networks[J].IEEE Transactions on wireless communications, 2002,1(4):660-670 [9] Vinh T T,Quynh T N.EMRP:Energy-Aware Mesh Routing Protocol for Wireless Sensor Networks[C]∥Advanced Tech- nologies for Communications(ATC),2012International Confer- ence on.IEEE,2012:78-82 [10]Jia Yun-jie,Liu Ming,et al.A clustering routing algorithm based on energy and distance in WSN[C]∥Computer Distributed Control and Intelligent Environmental Monitoring (CDCIEM), 2012International Conference on.IEEE,2012:9-12 [11]蒋畅江,石为人,唐贤伦,等.能量均衡的无线传感器网络非均匀 分簇路由协议[J].软件学报,2012,23(5):1223-1232 ·21·
还剩4页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 5 金币 [ 分享pdf获得金币 ] 0 人已下载

下载pdf