|
//*************************************************************
译序
初学linux系统,感觉linux底下的编译,链接程序真的很麻烦。
因此想到了用Autoconf等工具。找到了Autobook这本好书。
也不知道有没有人翻译过这本书。
该书由女友Ellen翻译,在此对她表示感谢。
该书原文请参考 http://sources.redhat.com/autobo ... obook_29.html#SEC29
如果翻译时有什么错误请
Ellengut2002@yahoo.com或者jasongut2002@126.com
转载请保留译序,3x.
//***************************************************************
6写`configure.in'
写一个可移植的`configure.in'文件是一件需要技巧的事。既然你能将shell的任意编码放置在`configure.in'中,你的选择似乎是决定一切。初次使用Autoconf的用户会问很多问题:什么结构是可移植的?什么结构是不可移植的?如何决定检查什么?我不能检查什么?如何才能充分利用Autoconf特性?什么是不能放置在configure.in'中?应该按什么顺序运行我的检查?我在什么时候应该看系统名称而不是检查具体特性?
6.1什么是可移植性
在我们讨论决定检查内容和方式的机制之前,我们先问自己一个简单的问题:什么是可移植性?可移植性是允许代码在不同平台上创建和运行的一种性质。在Autoconf的上下文,可移植性通常指在类Unix系统上(有时也包括Windows)运行的能力。
当我刚开始使用Autoconf时,我也难以决定在我的`configure.in'中检查什么。当时,我正在维护只能在SunOS 4上运行的专用程序。但是我很想将它移植到Solaris, OSF/1,有可能的话,甚至将它移植到Irix。
虽然我采用的方法达到了目的,但是它是相当费时而且很痛苦:我先写了一个最小的`configure.in',然后简单地尝试在Solaris上创建我的程序。每当我遇到一个创建问题时,我就更新configure.in'和我的源代码,然后重新开始。一旦它正确创建完毕,我开始测试是否存在与可移植性相关的运行时间问题。
既然我并不在相对可移植的平台上开始我的工作,而且我也没意识到可以使用工具将Autoconf支持添加到软件包中(参见24. Migrating an Existing Package to GNU Autotools),该项工作的难度就比原本的难度更高。如果可能的话,一开始就写可移植的代码要显然好得多。
全世界有很多类Unix系统,其中还包括许多已经过时但仍然在使用的系统。虽然有可能将一些程序移植到所有这些系统中,但是这种尝试并没有实际用处。将程序移植到所有的系统中是很困难,因为不可能在所有的平台上运行测试,何况每年又有新的操作系统(这些系统又各有自己的错误和特性)和发布。
我们提倡一种实用的方法来处理可移植性:我们以类Unix系统家族中一些比较现代的成员为目标编写程序。当在我们的可移植性框架中发现缺陷时,我们就更新`configure.in'和我们的源代码,然后再继续我们的工作。实际上,这是种有效的处理方法。 |
|