原创 翻译automake参考书9

2008-6-13 15:50 2537 7 7 分类: 工程师职场

    这是redhat公司提供的automake book,我为了学习英语翻译一下,见笑了。遵循GPL协议。


9. A Small GNU Autotools Project<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />


This chapter introduces a small--but real--worked example, to illustrate阐述 some of the features, and highlight强调 some of the pitfalls缺陷, of the GNU Autotools discussed so far. All of the source can be downloaded from the book's web page(5). The text is peppered with my own pet ideas, accumulated积累 over a several years of working with the GNU Autotools and you should be able to easily apply these to your own projects. I will begin by describing some of the choices and problems I encountered during the early stages of the development of this project. Then by way of illustration of the issues covered, move on to showing you a general infrastructure基础结构 that I use as the basis for all of my own projects, followed by the specifics of the implementation实现 of a portable command line shell library. This chapter then finishes with a sample shell application that uses that library.


Later, in 12. A Large GNU Autotools Project and 20. A Complex GNU Autotools Project, the example introduced here will be gradually逐渐 expanded as new features of GNU Autotools are revealed披露显示.


9.1 GNU Autotools in Practice


This section details some of the specific problems I encountered when starting this project, and is representative有代表性的 of the sorts of things you are likely to want to do in projects of your own, but for which the correct solution may not be immediately evident. You can always refer back to this section for some inspiration灵感 if you come across similar situations. I will talk about some of the decisions I made about the structure of the project, and also the trade-offs for the other side of the argument -- you might find the opposite choice to the one I make here is more relevant有关的 a particular project of yours.


<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />9.1.1 Project Directory Structure


Before starting to write code for any project, you need to decide on the directory structure you will use to organise the code. I like to build each component of a project in its own subdirectory, and to keep the configuration sources separate from the source code. The great majority of GNU projects I have seen use a similar method, so adopting采纳、采取 it yourself will likely make your project more familiar to your developers by association.


The top level directory is used for configuration files, such as `configure' and `aclocal.m4', and for a few other sundry杂项的 files, `README' and a copy of the project license for example.


Any significant libraries will have a subdirectory of their own, containing all of the sources and headers for that library along with a `Makefile.am' and anything else that is specific to just that library. Libraries that are part of a small like group, a set of pluggable可插入的 application modules for example, are kept together in a single directory.


The sources and headers for the project's main application will be stored in yet another subdirectory, traditionally named `src'. There are other conventional directories your developers might expect too: A `doc' directory for project documentation; and a `test' directory for the project self test suite.


To keep the project top-level directory as uncluttered整洁的 as possible, as I like to do, you can take advantage of Autoconf's `AC_CONFIG_AUX_DIR' by creating another directory, say `config', which will be used to store many of the GNU Autotools intermediate中间的 files, such as install-sh. I always store all project specific Autoconf M4 macros to this same subdirectory.


So, this is what you should start with:


$ pwd


~/mypackage


$ ls -F


Makefile.am  config/     configure.in  lib/  test/


README       configure*  doc/          src/


9、一个小型的gnu autotools工程


       本章介绍一个小型的但是可以运行的实例,通过这个实例来说明GNU Autotools的一些特征,并且也会强调这些工具的缺陷。关于这个实例的所有源文件都可以从本书的网页上下载。在本书中增加了一些我自己的经验,这些经验是我在多年使用GNU Autotools过程中积累下来的,并且读者可以轻松的把这些经验应用到自己的工程中。为了解释涉及到的各种问题,接下来为读者介绍一个通用工程结构,我自己常常把这个结构作为我开发项目的基础,再这之后是一个可移植的命令行shell库的具体实现。本章最后用一个使用该库的shell程序作为结尾。


       在后续的12章和20章,这个实例逐渐使用更多GNU Autotools特性来扩展。


9.1     GNU Autotools实践


本节将详细介绍我在项目开始时遇到的一些具体问题,以及读者在项目开发过程中想知道的一些有代表性的事情,但是正确的方案也不是一下子就能被发现。当读者遇到类似的状况时你可以返回到本小节来寻找一点灵感。我将会讨论关于工程结构的决议和一些折中的选择,读者可能会发现有些地方我会做出截然不同的选择,但是这些选择可能更适合一些特定的项目。


9.1.1          工程的目录结构


当你为任何项目编写代码之前,你必须决定用何种目录结构来组织你的代码。我的做法是把项目的各个部分放在相应的子目录下面,并且源代码的配置文件和源代码分离开来。大部分我见过的GNU项目也是采取类似的方法,所以如果你也采取类似的策略的话,可以使你的同事能更快的熟悉你的代码。


顶层目录下面一般存放一些配置文件,比如configureaclocal.m4。当然也包含一些其它的文件,比如README和项目的授权文件等。


所有重要的库文件也需要存放在自己的子目录中,包括所有除Makefile.am的跟程序库有关程序文件、头文件以及程序库的特殊文件。当库文件比较小时,比如说是一些可服用的程序模块,通常存放在一个单独的目录中。


跟项目主程序有关的源码文件和头文件存放在另外的子目录中,通常为src目录。在项目开发中还可能需要一些其它的目录:doc目录用来存放项目的文档、test目录存放项目的测试实例。


为了是顶层目录看起来简洁一些,我通常利用autoconf提供的宏AC_CONFIG_AUX_DIR来创建其它的目录,比如config目录。Config目录常用来存放一些GNU Autotools会使用到的中间文件,比如install-sh。我自己常常把所有跟项目有关的Autoconf M4宏也存放在config目录下。


最后结果看起来应该如下所示:


$ pwd


~/mypackage


$ ls –F


Makefile.am    config/    configure.in    lib/   test/


README       configure*      dec/        src/


 

文章评论0条评论)

登录后参与讨论
我要评论
0
7
关闭 站长推荐上一条 /2 下一条