Configure 的發展

2.3 Configure Development / Configure 的發展

The Cygnus `configure' script and the original GCC `configure' script both had to be updated for each new Unix variant they supported. This meant that packages which used them were continually out of date as new Unix variants appeared. It was not hard for the developer to add support for a new system variant; however, it was not something which package users could easily do themselves.

Cygnus 的 `configure' 指令稿與 GCC 原始的 `configure' 指令稿都必須針對所支援的 Unix 衍生作業系統做出修改，這代表當新的 Unix 衍生作業系統出現時，使用了這兩樣工具的軟體套件必須修改才能用在新的作業系統上。對於軟體的發展者而言，修改軟體套件以支援新的作業系統可能並非難事；但是對於軟體套件的使用者而言，這就不是件容易自己搞定的事情。

The same was true of Imake as it was commonly used. While it was possible for a user to build and configure Imake for a particular system, it was not commonly done. In practice, packages such as the X window system which use Imake are shipped with configuration information detailed for specific Unix variants.

被漸漸廣泛使用的 Imake 也面臨一樣的問題，雖然使用者自己針對特定系統建置並設定 Imake 不是難到不可能的事，但其實很少使用者這麼做。在實務上，像 X window 這類使用 Imake 的軟體套件，會帶有針對各個不同的 Unix 衍生作業系統所撰寫的配置檔。

Because Metaconfig and Autoconf used feature tests, the scripts they generated were often able to work correctly on new Unix variants without modification. This made them more flexible and easier to work with over time, and led to the wide adoption of Autoconf.

因為 Metaconfig 與 Autoconf 是利用一序列的測試來決定系統提供的功能，因此所產生的組態指令稿通常不用修改就能在新的 Unix 衍生作業系統上正確執行。這樣的特性讓這兩項工具被視為具彈性且不用頻繁維護的方案，並使 Autoconf 被大量採用。

In 1994, David MacKenzie extended Autoconf to incorporate the features of the Cygnus `configure' script and the original GCC `configure' script. This included support for using system specified header file and makefile fragments, and support for cross-compilation.

在 1994 年 David MacKenzie 將 Autoconf 加以擴充，納入了 Cygnus 的 `configure' 指令稿與原始的 GCC `configure' 指令稿的功能。這次擴充使 Autoconf 支援針對不同系統使用不同的標頭檔或 makefile 檔案片段，另外也支援了跨平臺編譯。

GCC has since been converted to use Autoconf, eliminating the GCC `configure' script. Most programs which use the Cygnus `configure' script have also been converted, and no new programs are being written to use the Cygnus `configure' script.

從此之後，GCC 便轉而使用 Autoconf 並揚棄了原本的 GCC `configure' 指令稿。大多數使用 Cygnus `configure' 指令稿的程式也改用 Autoconf，新的程式也不再使用 Cygnus `configure' 指令稿。

The metaconfig program is still used today to configure Perl and a few other programs. imake is still used to configure the X window system. However, these tools are not generally used for new packages.

Metaconfig 在今日仍被用在 Perl 與幾個其他程式的建置中進行組態工作，Imake 也仍被用來組態 X window 系統。但是，在新的軟體套件中就很少會去使用這些工具了。

twitter

鈍鈍的，大概是 AJAX 用太兇了。

實在是沒想到有什麼用，以後 imbot 有什麼動作的話，就丟上去好了，性質似乎蠻合的。

在 OS X 上裝 CPAN module

沒有想像中可怕，不過 HFS+ 的不分辨大小寫功能的確是會造成問題。

找到這篇文章提到，重點在於設定 cpan 的時候，要讓他把 "INSTALLBIN=/usr/local/bin INSTALLSCRIPT=/usr/local/bin" 設為 perl Makefile.PL 的參數。

從 which 來看，用的應該還是原本 OS X 的 perl 程式，不過 fink 會把 library 的目錄讓他先去搜尋 fink 的 lib 目錄，這是比較稍微有點讓人擔心的地方，其他都蠻正常的。

裝電腦或修電腦這件事

最近又開始有人找我幫忙電腦的問題，不知道是不是天氣冷了，於是大家與電腦接觸的時間長了，就開始有一些怨言。

基本上就是不幫忙，我處理這幾件事的重點是:

裝電腦

原則上，我是不會特地幫忙裝電腦或買電腦，除非我自己剛好也有要買，或是周遭剛好有要出採購團。

列零件配備的話，也是抱歉，不過這裡有張我之前列的表，可以參考看看。這個表有一段時間了就是，大概只能參考牌子吧！

要買電腦，然後自己沒有辦法組裝或挑零件的話，其實我是比較建議買品牌電腦。因為或多或少會有需要維修的時候，有的品牌有提供到府收送，這樣會方便很多，不用自己累得半死搬到店家去。

至於建議的牌子，桌上型的話: ASUS, Dell 。要注意的是，如果是 ASUS 的話，不是所有代理商都有提供到府收送，這是要注意的地方。 Dell 的話，到府收送是一個搭配不同的處理時間保證的選購項目，要弄清楚。

筆記型電腦的話: ASUS 。主要是東西相較之下不是太貴，國內維修點也多。如果要出國的話，可能要看各廠牌對你去的國家維修支援的狀況，問問當地人會比較好。

很多人會問日系品牌到底好不好，就我看，日系機器不見得品質有多好到哪去，尤其有些中低價位的型號根本是委託臺灣廠設計，考量到使用壽命與價格不見得會比較值得。

修電腦

基本上，我並不幫忙修電腦，除非是我的程式的問題，否則我不處理也不檢視。

這種事情我是覺得，女人自己不會修可以去找自己的男人，基本上是男人就應該會修電腦，找不到會修電腦的男人的話，也還是可以上店家花點錢處理。把這種成本轉嫁到無關的人身上，並且沒有相對的報酬，實在蠻過分的。

灌電腦

這個，同上，請自行想辦法處理。

說實在的啦！找認識的人處理電腦問題，十之八九也只是為了免費而已，甚至有的人還會多方徵詢意見，弄了半天結果一點也沒派上用場，感覺實在是挺差的。

「時代已經不同了，這年頭癡情的只有被發卡的份而已。」這是在一篇頗無聊的文章內看到的話，從某種角度而言，這句話道盡了人際關係間的現實啊！

說到修電腦這檔事，主要牽涉到的就是時間與金錢。處理要時間，如果有硬體壞了差不多就得要錢。

雖然時間耗的是出手修的人的時間，不過還是得看找人來修的那位的心態如何。有個朋友，姑且稱之為宅宅好了，去幫一位認識的女生修電腦，好像有個系統檔被置換掉了，總之就是弄很久才解決，花了一整個下午吧！

後來聽熟悉內部情報人士透露，這個下午那個女生的男朋友來找她，總之女生怕宅宅不高興，於是這個男生就被支在外面。後來，女生這邊抱怨說電腦弄的太久了，本來那整個下午她要跟她男友好好翻雲覆雨一翻，結果卻得陪這個宅宅。

比較麻煩的是，通常大家都有很多活動，所以一些要花長時間找的問題就比較尷尬。看到問題，處理好也不是，不處理好又是一個疙瘩。

金錢方面相對是小事，只是算起來還是不太好看，通常我會告訴他們可能是哪個東西壞了，叫他們整台抱去檢修看看。當然，也是有人請我代購，不過有過一次經驗，千里迢迢從號稱實際售價最便宜的光華商場買回來，然後被嫌貴。比較誇張的是，買回來換上去兩三個月後，跟我抱怨現在買比較便宜... 碼的，明年買的話同樣價格功能還更棒咧！

簡言之，不論是就金錢，還是時間而論，修電腦都是件吃力不討好的蠢事。

裝電腦大概比修電腦好一點，至少比較不會遇到那種很怪異難解的問題，不過一樣是浪費時間。一開始可能至少會對搞定系統有點成就感，久了就會對插插拔拔膩了，雖然其實都是小事。

所以，現在我就不太幫修電腦、裝電腦、重裝諸如 Windows, Office 之類的軟體... 花時間，花下去看到的都是負面的，沒什麼實際的好處。

要說對人際關係有什麼好處，我是沒看到啦！會找的那些人，難得有事來找就是修電腦，要玩要幹嘛並是不會來找。

當然，也是因為玩樂的事情來找也玩不起來就是，講白了，根本就不熟啊！熟的，平常出去吃飯打混，電腦有問題問個兩句就解決了，有什麼重要的情報也直接交換，反而感覺上並不太會有需要處理電腦相關事務的時候。

Bonjour on Windows

這東西在標準的名稱是 Zeroconf ，不過各家廠商有各家的叫法。 Apple 算是最誇張的吧！完全抹掉 Zeroconf 這個名字。

總之，對於小型的區域網路來講，的確蠻方便的。主機安裝時都會設有名稱，裝了之後，就可以利用這個名稱轉換成 Zeroconf 的 .local 網域名稱。

在 Windows 上 Apple 有提供 Bonjour for Windows 給 Windows 使用，試了一下，的確可以順利的使用 .local 來完成名稱正解。

關閉光碟自動安插通知

從 Windows98 之後，似乎就不太能輕鬆的完全關掉這項有點麻煩的功能。

要關掉 AutoRun 似乎是修改 HKLM\SYSTEM\CurrentControlSet\Services\Cdrom\ 下的 Autorun 設為 0 值。

要關掉 AutoPlay 的話，可能就得靠 TweakUI 了。除了 TweakUI 本身提供的設定界面，還可以從 TweakUI 進入 Group Policy Editor 編輯 Computer Configuration / Administrative Templates / System 下的 Turn autoplay off 這個選項，把他 Enable 起來。

參考資料: AutoPlay - Wikipedia

最初的 configure 程式

2.2 The First Configure Programs / 最初的 configure 程式

By 1992, four different systems had been developed to help with source code portability:

為了增進原始碼的可攜性，在 1992 年有四個不同的解決方案被開發出來:

• The Metaconfig program, by Larry Wall, Harlan Stenn, and Raphael Manfredi.

  Metaconfig ，由 Larry Wall 、 Harlan Stenn 以及 Raphael Manfredi 所發展。

• The Cygnus `configure' script, by K. Richard Pixley, and the original GCC `configure' script, by Richard Stallman. These are quite similar, and the developers communicated regularly. GCC is the GNU Compiler Collection, formerly the GNU C compiler.

  K. Richard Pixley 為 Cygnus 發展的 `configure' 指令稿；以及由 Richard Stallman 當初為 GCC 撰寫的 `configure' 指令稿， GCC 是 GNU Compiler Collection 的縮寫，其前身為 GNU C compiler 。這兩個指令稿非常相似，兩位發展者也經常交換意見。

• The GNU Autoconf package, by David MacKenzie.

  GNU Autoconf ， David MacKenzie 所發展。

• Imake, part of the X Window system.

  Imake ，屬於 X Window 的一部份。

These systems all split building a program into two steps: a configuration step, and a build step. For all the systems, the build step used the standard Unix make program. The make program reads a set of rules in a `Makefile', and uses them to build a program. The configuration step would generate `Makefile's, and perhaps other files, which would then be used during the build step.

這些解決方案都把建置程式的過程分為兩個步驟: 組態，以及建置。在所有系統上，建置的程序會由 make 這個標準的 Unix 程式進行。 make 程式會由一個稱為 `Makefile' 的描述檔中讀取建置規則，並依據這些規則編譯程式。在建置作業前的組態階段，則會產生建置所需的 `Makefile' 以及其他建置時所需的檔案。

Metaconfig and Autoconf both use feature tests to determine the capabilities of the system. They use Bourne shell scripts (all variants of Unix support the Bourne shell in one form or another) to run various tests to see what the system can support.

Metaconfig 與 Autoconf 都透過執行一序列的測試程式來決定系統的功能與能提供的工具，這兩個工具的測試程式都是用 Bourne shell 指令稿所撰寫的。 (幾乎所有由 Unix 所衍生的作業系統都某種程度的支援 Bourne shell)

The Cygnus `configure' script and the original GCC `configure' script are also Bourne shell scripts. They rely on little configuration files for each system variant, both header files and `Makefile' fragments. In early versions, the user compiling the program had to tell the script which type of system the program should be built for; they were later enhanced with a shell script written by Per Bothner which determines the system type based on the standard Unix uname program and other information.

Cygnus 的 `configure' 指令稿以及 GCC 原始的 `configure' 指令稿也是使用 Bourne shell 指令稿所撰寫的， Cygnus 與 GCC 針對不同的系統平台分別提供了一組特定的系統組態檔、標頭檔、以及指引編譯流程的 `Makefile' 描述檔。在早期的版本，要建置軟體的使用者必須告訴 `configure' 指令稿建置出來的程式的目標執行平台是什麼；後來 Per Bothner 修改了 `configure' 指令稿，讓 `configure' 可以自己利用 uname 這個標準的 Unix 程式以及其他系統環境的資訊來決定目標執行平台。

Imake is a portable C program. Imake can be customized for a particular system, and run as part of building a package. However, it is more normally distributed with a package, including all the configuration information needed for supported systems.

Imake 是一個用 C 語言所撰寫的程式，他具有高度的可攜性。 Imake 可以針對特定作業系統客制化，並在爾後建置軟體套件時使用。不過，通常 Imake 會與軟體套件一起被散佈，套件檔案中會附上在套件所支援的系統上建置軟體所需的組態資訊。

Metaconfig and Autoconf are programs used by program authors. They produce a shell script which is distributed with the program's source code. A user who wants to build the program runs the shell script in order to configure the source code for the particular system on which it is to be built.

Metaconfig 與 Autoconf 是給程式設計師使用的工具，兩者都會產生出隨著軟體原始碼散佈用的 shell 指令稿。要建置軟體的使用者可以執行由 Metaconfig 或是 Autoconf 產生的 shell 指令稿，以將程式原始碼針對執行建置作業的系統環境作調整。

The Cygnus and GCC `configure' scripts, and imake, do not have this clear distinction between use by the developer and use by the user.

Cygnus 與 GCC 的 `configure' 指令稿，以及 Imake ，就比較沒有如此的清楚區分說哪部份要由程式設計師使用，哪個部份是給建置套件的使用者使用。

The Cygnus and GCC `configure' scripts included features to support cross development, both to support building a cross-compiler which compiles code to be run on another system, and to support building a program using a cross-compiler.

Cygnus 與 GCC 的 `configure' 指令稿支援了跨平台程式發展的功能，兩者都支援建置 cross-compiler ，或是利用 cross-compiler 建置程式。利用 cross-compiler ，可以編譯出執行在與編譯器執行平台相異的作業平台的機械碼。

Autoconf, Metaconfig and Imake did not have these features (they were later added to Autoconf); they only worked for building a program on the system on which it was to run.

Autoconf 、 Metaconfig 與 Imake 都不支援這些跨平台程式發展功能 (不過後來 Autoconf 有加入了這些功能) ；這些工具只能用來建置在建置環境中執行的程式。

The scripts generated by Metaconfig are interactive by default: they ask questions of the user as they go along. This permits them to determine certain characteristics of the system which it is difficult or impossible to test, such as the behavior of setuid programs.

由 Metaconfig 所產生出來的指令稿，在預設下是需要與使用者互動的: 在建置過程中，指令稿會問使用者一些問題。這個設計是為了取得一些比較難以自動偵測的系統組態與特性，比如說 setuid 程式的行為模式。

The Cygnus and GCC `configure' scripts, and the scripts generated by autoconf, and the imake program, are not interactive: they determine everything themselves. When using Autoconf, the package developer normally writes the script to accept command line options for features which can not be tested for, or sometimes requires the user to edit a header file after the `configure' script has run.

Cygnus 與 GCC 的 `configure' 指令稿、由 Autoconf 所產生的指令稿、以及 Imake 等這三者則相反，他們執行時不與使用者互動: 這些工具會自己做出所有關於環境特性的決定。如果要取得無法利用測試偵測出來的系統組態或特性，一般而言，套件發展者會撰寫額外的指令稿讓使用者可以利用指令列參數告知系統組態，或是，有時候可能會要求使用者在執行完 `configure' 指令稿後編輯一個特定的標頭檔，好指出系統的組態。

Unix 系統間的歧異

2.1 The Diversity of Unix Systems / Unix 系統間的歧異

Of the programs discussed in this book, the first to be developed was Autoconf. Its development was determined by the history of the Unix operating system.

在本書所討論的工具程式中，第一個被發展出來的工具是 Autoconf ，這個工具的發展與 Unix 作業系統的歷史習習相關。

The first version of Unix was written by Dennis Ritchie and Ken Thompson at Bell Labs in 1969. During the 1970s, Bell Labs was not permitted to sell Unix commercially, but did distribute Unix to universities at relatively low cost. The University of California at Berkeley added their own improvements to the Unix sources; the result was known as the BSD version of Unix.

第一版的 Unix 是在 1969 年由 Dennis Ritchie 與 Ken Thompson 在 Bell Labs 所寫出來的。在 1970 年代，雖然 Bell Labs 的母公司並未將 Unix 商業化販售，但是 Bell Labs 還是有將 Unix 以相對低廉的價格散佈到大學校園內。加州大學柏克萊分校的研究人員將他們的研究成果加入了 Unix 的原始碼中，這個增強後的版本就是後來為眾人所知的 BSD 版 Unix 系統。

In the early 1980s, AT&T signed an agreement permitting them to sell Unix commercially. The first AT&T version of Unix was known as System III.

在 1980 年前期 AT&T 開始商業販售 Unix 作業系統，第一個 AT&T 的 Unix 版本稱為 System III 。

As the popularity of Unix increased during the 1980s, several other companies modified the Unix sources to create their own variants. Examples include SunOS from Sun Microsystems, Ultrix from Digital Equipment Corporation, and HP-UX from Hewlett Packard.

Unix 在 1980 年代開始普及，許多其他的公司也修改了 Unix 的原始碼並衍伸出自己的作業系統。比如，昇陽電腦的 SunOS ，迪吉多電腦的 Ultrix，以及惠普電腦的 HP-UX 。

Although all of the Unix variants were fundamentally similar, there were various differences between them. They had slightly different sets of header files and slightly different lists of functions in the system libraries, as well as more significant differences in areas such as terminal handling and job control.

雖然所有由 Unix 衍伸出的作業系統在設計上的出發點是相似的，但仍有相當的相異。他們有不同的標頭檔，系統函式庫所提供的函式呼叫也不太一樣，在終端機的控制以及工作的管理上也有可觀的差異。

The emerging POSIX standards helped to eliminate some of these differences. However, in some areas POSIX introduced new features, leading to more variants. Also, different systems adopted the POSIX standard at different times, leading to further disparities.

雖然 POSIX 標準的推出協助消弭了一些歧異，但是，因為 POSIX 也提出了一些新的功能，所以 POSIX 也引出了更多歧異。此外，隨著 POSIX 的改版，新舊版本的標準間也存在著差異，連帶使得不同時期推出的作業系統也因為採用了不同版本的標準而有歧異。

All of these variations caused problems for programs distributed as source code. Even a function as straightforward as memcpy was not available everywhere; the BSD system library provided the similar function bcopy instead, but the order of arguments was reversed.

當以原始碼形式散佈程式時，這些作業系統間的歧異會造成困擾。就算是 memcpy 這類基本的函式也不見得在所有平台上都支援；比如說，在 BSD 的系統函式庫中，提供這項功能的是叫做 bcopy 的函式，不過他的參數順序與 memcpy 是正好顛倒的。

Program authors who wanted their programs to run on a wide variety of Unix variants had to be familiar with the detailed differences between the variants. They also had to worry about the ways in which the variants changed from one version to another, as variants on the one hand converged on the POSIX standard and on the other continued to introduce new and different features.

如果程式設計師想讓程式能在各種由 Unix 衍伸出的系統上運作，他就得對各家衍伸系統間的差異非常了解。另外，作業系統可能為了符合 POSIX 標準或是引入新的功能而改版，進而造成版本間的歧異，這也是程式設計師得面對的問題。

While it was generally possible to use #ifdef to identify particular systems and versions, it became increasingly difficult to know which versions had which features. It became clear that some more organized approach was needed to handle the differences between Unix variants.

一般來講可以用 #ifdef 來辨認出平台所採用的作業系統與版本，但是，，要知道哪個版本有什麼功能則是越來越不容易。因此，程式設計師們漸漸明確的知道，需要一個系統化的方法來處理不同 Unix 衍伸系統間的差異。

發展歷史

2. History / 發展歷史

In this chapter we provide a brief history of the tools described in this book. You don't need to know this history in order to use the tools. However, the history of how the tools developed over time helps explain why the tools act the way that they do today. Also, in a book like this, it's only fair for us to credit the original authors and sources of inspiration, and to explain what they did.

在這一章，我們會簡單的描述一下本書主角 Autotools 的發展歷史。你不需要知道這些歷史就可以將這些工具上手，但是，了解這些工具程式的發展歷史可以幫助你理解為什麼這些工具的行為是今日你所見的這樣。此外，本書也要藉此機會向這些工具程式的創造者與貢獻者致敬，並解釋他們當初作下的設計決策背後的原因。

本書的組織方式

1.4 How this book is organized / 本書的組織方式

Like any good tutorial, this book starts with an explanation of simple concepts and builds on these fundamentals to progress to advanced topics.

如同所有優秀的入門文件一樣，這本書從簡單的概念開始，然後以這些簡單的概念為基礎，擴充到較複雜的主題上。

Part I of the book provides a history of the development of these tools and why they exist.

這本書的第一部份描述這些工具軟體的發展歷史，以及他們被發展出來的原因。

Part II contains most of the book's content, starting with an introduction to concepts such as `Makefile's and configuration triplets. Later chapters introduce each tool and how to manage projects of varying sizes using the tools in concert. Programs written in C and C++ can be non-portable if written carelessly. Chapters 14 and 15 offer guidelines for writing portable programs in C and C++, respectively.

本書的第二部份包含了大部分的內容，首先從介紹概念開始，如 `Makefile' 以及 configuration triplet 等等。接下來的章節會分別介紹如何使用 Autotools 的工具，以及如何利用這些工具管理不同規模的專案。最後，在 14 與 15 章中將會介紹使用 C/C++ 撰寫程式時需要注意的可攜性議題，撰寫 C/C++ 程式時若不特別注意的話，很容易會寫出無法移植的程式。

Part III provides information that you are unlikely to find in any other documentation, that is based on extensive experience with the tools. It embodies chapters that treat some advanced, yet essential, concepts such as the m4 macro processor and how to write portable Bourne shell scripts. Chapter 23 outlines how to migrate an existing package to the GNU Autotools framework and will be of interest to many developers. One of the most mystifying aspects of using the GNU Autotools for building packages in a cross-compilation environment. This is de-mystified in Chapter 25.

一些在其他文件中比較難找到的資訊被放在第三部份中，這些內容是以大量的實務經驗為基礎而撰寫的。首先，一些較進階並且重要的主題會在這部份討論，比如 m4 巨集處理器以及撰寫具可攜性的 Bourne shell 指令稿的注意事項。在第 23 章會提到如何將現有的專案移到 GNU Autotools 框架中，這部份會是很多發展者有興趣的地方。在第 25 章會解釋如何在 cross-compilation 環境中使用 GNU Autotools 來管理專案。

這本書的目標讀者

1.3 Who should read this book / 這本書的目標讀者

Revealing the mystery around the GNU Autotools is likely to raise the interest of a wide audience of software developers, system administrators and technical managers.

本書旨在揭開 GNU Autotools 背後運作原理的神祕面紗，我們相信這將會引起不少的軟體發展者、系統管理員，以及技術經理的興趣。

Software developers, especially those involved with free software projects, will find it valuable to understand how to use these tools. The GNU Autotools are enjoying growing popularity in the free software community. Developers of in-house projects can reap the same benefits by using these tools.

對軟體發展者來說，特別是有參與自由軟體專案的發展者，他們將會發現了解如何使用 Autotools 是非常有用的。隨著加入自由軟體社群的發展者增加，使用 GNU Autotools 的發展者也日益增加。對於為私人機構或公司執行專案的發展者，他們也可以在他們的專案中使用 Autotools 並從中得到一些益處。

System administrators can benefit from a working knowledge of these tools -- a common task for system administrators is to compile and install packages which commonly use the GNU Autotools framework. Occasionally, a feature test may produce a false result, leading to a compilation error or a misbehaving program. Some hacking is usually sufficient to get the package to compile, but knowing the correct way to fix the problem can assist the package maintainer.

系統管理員也可以從了解這些工具如何運作中得到益處 -- 有很多的軟體套件使用了 Autotools 作為建置框架，而編譯與安裝軟體套件恰巧是系統管理員經常要進行的工作。有時候，進行作業環境偵測時會發生錯誤，並導致編譯失敗，或是程式的不正常運作。雖然一些鋸箭療法般的處置通常已足以讓軟體正常編譯，但是了解正確的修正方式可以幫助套件的維護者在上游直接修復套件中的錯誤。

Finally, technical managers may find the discussion to be an insight into the complex nature of software portability and the process of building a large project.

最後，本書對於軟體可攜性以及大型專案建置面臨的複雜問題的討論，也能讓技術經理從中得到一些心得。

這本書未涵蓋到的範圍

1.2 What the book is not / 這本書未涵蓋到的範圍

This book is not a definitive reference to Autoconf, Automake or Libtool. Attempting to do so would fill this book with information that is doomed to obsolescence. For instance, you will not find a description of every predefined macro provided by Autoconf. Instead, the book will attempt to help you understand any macro you encounter and, instead, influence how you approach software portability and package building. The GNU manual for each tool should be consulted as a reference.

這本書並不是 Autoconf, Automake 或 Libtool 的完整使用手冊，如果把所有功能都寫入這本書的話，那麼這本書將會充滿一些即將過時的資訊。換言之，你不會在這本書中找到所有 Autoconf 預先定義好的巨集，然而，這本書會試著協助你理解你所碰到的任何巨集，並指引你一個增進軟體可攜性的方向。當你需要這些工具的完整參考手冊時，可以參考各工具的 GNU 手冊。

This book briefly introduces pertinent concepts, but does not attempt to teach them comprehensively. You will find an introduction to writing `Makefile's and Bourne shell scripts, but you should consult other references to become familiar with these broader topics.

對於一些相關的工具，這本書會簡單的介紹他們的使用概念，但不會很詳細並完整的解釋他們。比如說，你可以在這本書中找到撰寫 `Makefile' 或是 Bourne shell 指令稿的初步介紹，但當你想要對這些主題更了解，你就得要閱讀其他專門討論這些工具的參考文件。

這本書所討論的範圍

1.1 What this book is / 這本書所討論的範圍

This book is a tutorial for Autoconf, Automake and Libtool, hereafter referred to as the GNU Autotools. The GNU manuals that accompany each tools adequately document each tool in isolation. Until now, there has not been a guide that has described how these tools work together.

這本書是 Autoconf, Automake 以及 Libtool 的入門書，這三個工具軟體在本書會以 GNU Autools 稱之。雖然這些工具的用法已經在隨附的 GNU 使用手冊中已充分的記載，但在手冊中這幾件工具是被分開討論的。直到本書撰寫前，都沒有一個使用指引描述這些工具要如何一起使用這些工具。

As these tools have evolved over the years, design decisions have been made by contributors who clearly understand the associated problems, but little documentation exists that captures why things are the way they are. By way of example, one might wonder why some Autoconf macros use shell constructs like:

隨著這些工具的發展，有很多了解所有關連問題的工程師做出設計決策，並貢獻出程式碼。然而，卻只有很少量的文件描述這些設計決策的來龍去脈。比如說，可能有人會好奇，為什麼有些 Autoconf 的巨集使用下面的 shell script 寫法:

if test "x$var" = xbar; then echo yes 1>&5 fi

instead of the simpler:

而不用較精簡的:

if [ $var = bar ]; then echo yes 1>&5 fi

Much of this reasoning is recorded in this book.

有很多這類決策的來龍去脈，都記錄在這本書中。

序曲

1. Introduction / 序曲

Autoconf, Automake and Libtool are packages for making your software more portable and to simplify building it--usually on someone else's system. Software portability and effective build systems are crucial aspects of modern software engineering practice. It is unlikely that a software project would be started today with the expectation that the software would run on only one platform. Hardware constraints may change the choice of platform, new customers with different kinds of systems may emerge or your vendor might introduce incompatible changes in newer versions of their operating system. In addition, tools that make building software easier and less error prone are valuable.

Autoconf, Automake 以及 Libtool 是用來讓你所開發的軟體能更具可攜性，且更容易在別人的電腦系統上編譯的工具套件。近年來，軟體的可攜性與有效率的編譯與建置系統在近代軟體工程實務上漸漸佔有重要的一席之地。因為種種原因，在現在很少有軟體開發專案會在開始時就決定只支援單一平台。比如說: 硬體的限制可能會影響平台的選擇，使用不同系統平台的客戶可能會出現，或是您的作業系統軟體供應商可能會做出與舊系統不相容的變更。除此之外，能夠簡化並減少軟體編譯建置之流程與錯誤的工具是相當有價值的。

Autoconf is a tool that makes your packages more portable by performing tests to discover system characteristics before the package is compiled. Your source code can then adapt to these differences.

Autoconf 是一個可以讓你的軟體更具可攜性的工具，他會在編譯前執行一序列測試程式找出系統所安裝軟體的狀況，你的程式碼可以據此在不同的系統之間調適。

Automake is a tool for generating `Makefile's--descriptions of what to build--that conform to a number of standards. Automake substantially simplifies the process of describing the organization of a package and performs additional functions such as dependency tracking between source files.

Automake 是一個用來產生 `Makefile' -- 指出有哪些東西要編譯或建置的描述檔 -- 的工具。利用 Automake 可以大幅的簡化描述要建置套件內容的流程，並且可以提供一些額外的功能，如: 原始碼間的相依性檢查等等。

Libtool is a command line interface to the compiler and linker that makes it easy to portably generate static and shared libraries, regardless of the platform it is running on.

Libtool 是一個包裝了編譯器與鏈結器的命令列程式，這個工具可以為你產生靜態連結或動態連結的函式庫，你完全不用在意進行建置作業的系統平台到底是哪個。

AB 試譯

之前就想譯看看，不過半途而廢了。主要是想說弄個好用的工具，不過寫工具實在是挺辛苦的，而且前置作業太多要做了。

這次主要是可能會用到，算是比較急吧！所以想到直接放在 Blog 上。向後相容的部份，會使用 xml:lang 以及 div-tag 來作。版本管理就比較沒辦法了，只能以後再看看，剛好這本書已經差不多 freeze 了，所以這相對不是太大的問題。

樣式方面，會用 overflow: scroll; white-space: pre; 來處理 code 的呈現。

---

1. Introduction / 序曲
   1. What this book is / 這本書所討論的範圍
   2. What the book is not / 這本書未涵蓋到的範圍
   3. Who should read this book / 這本書的目標讀者
   4. How this book is organized / 本書的組織方式
2. History / 發展歷史
   1. The Diversity of Unix Systems / Unix 系統間的歧異
   2. The First Configure Programs / 最初的 configure 程式
   3. Configure Development / Configure 的發展
   4. Automake Development / Automake 的發展
   5. Libtool Development / Libtool 的發展
   6. Microsoft Windows / Microsoft Windows
3. How to run configure and make / 如何執行 configure 與 make
   1. Configuring / 進行組態
   2. Files generated by configure / 由 configure 所產生的檔案
   3. The most useful Makefile targets / 常用的 Makefile 建置目標

Safari 3

透過 Software Update 取得了，這應該也表示已經正式釋出了。

在 JavaScript 上的支援度看來是有提高，存取 Gmail 也可以得到與 Firefox 一樣的界面，也可以用內嵌的 Web-based Google Talk 了。

個人是特別期待整合所有視窗的功能，一堆視窗實在是頗不好用的。應該是因為我已經習慣了 Firefox 吧！

除去文件每行首尾空白的指令

從網頁，或是某些在每行前加了空白的 BBS Post 上貼文章到記事本前，可以用這個指令來把因為格式轉換等造成的前置與後置空白去除。

perl -e 'while($l = ) { $l =~ s/^\s+//; $l =~ s/\s+$//; print "$l\n"; }'

資料直接丟到 STDIN 就好了，輸出會從 STDOUT 出來。對長文章比較方便的用法可能是 redirect 到檔案裡再開吧！

設定 eclipse 的語系

主要是 subclipse 的問題，因為 subclipse 有中文語系檔，所以他就會盡可能的顯示語平台相符的語言。

不幸的是 eclipse 沒有中文語系檔，所以用起來就很怪，關於 SVN 的部份就有中文。更慘的是，看到經常會反應不太過來... 像是要 commit 還得找一下 orz|||

更新 fink 之中，順便找了一下 solution 看要怎麼處理比較適當，然後找到這篇。

簡單講，除了把作業系統設成英文版之外，可以改 eclipse.ini 檔，或是在啟動的捷徑中加參數。要加進去的參數是:

-nl
en_US

Mac 上沒有什麼啟動捷徑，所以改 eclipse.ini 是比較單純點。要注意的是，改 eclipse.ini 的話得像上面寫成兩行，並且必須在 -Vm 選項之上。

其他設定可以參考 Eclipse 3.3 Help: Workbench User Guide / Tasks / Running Eclipse 的說明。

Mozilla Firefox 2.0.0.8

總覺得更新到 2.0.0.7 沒幾天，程式又說要更新到 2.0.0.8 了。這次更新主要是 security 方面的修正，還算是挺重要的。

這就叫做，光陰似箭... 嗎？

無失真旋轉 JPEG 圖檔

就像大家知道的一樣，旋轉 JPEG 圖檔可以是無失真 (lossless) 的。

在 Linux 或是 Mac 或是 FreeBSD 上，可以用 libjpeg 附的 jpegtran 來處理。

指令就是 jpegtran -rotate 90 in.jpg > out.jpg

這個程式會把輸出往 STDOUT 倒，所以要取代原始檔案得另外自己刪除舊黨、改檔名。

在 Mac 下可以安裝 fink 的 libjpeg-bin 套件來取得 jpegtran 程式，或是不想裝 fink 的話，就得自己抓 libjpeg 來編譯了。

選字 → 查字典

以往都是把要查的字複製到字典網頁中，有點煩了，所以今天花了點時間希望能讓這個過程簡便一些。

就是這個: Yahoo!奇摩字典

不過我只有在 Firefox 上測試過就是，不知道其他瀏覽器上能不能用。

丟到 Bookmark Toolbar 上，瀏覽網頁時遇到要查的字只要選起來，然後按下這個 Bookmarklet 就會開啟新的視窗或是標籤頁，然後連到 Yahoo!奇摩字典去查詢要查的字。如果沒選字就按下這個 Bookmarklet 的話，就會直接在目前的視窗或標籤頁開啟 Yahoo!奇摩字典的首頁。

其實後來發現有不少一樣功能的東西別人已經寫好，內容其實差不多，動手前真是該先搜尋一下。

Google Docs 更新文件列表界面

今天下午大約四點多時發現的，可能剛好更新到我所在的主機，突然整個界面就變得不一樣，嚇我一大跳，還以為按到什麼東西。

更新之後的列表比較容易看到自己有什麼文件在手上，不過相對的似乎不是那麼容易把焦點集中在某些特定文件上。

另外就是似乎不會記住上次離開時的狀態，比如說所切換到的列表，或是 folder 的開啟或關閉狀態。

Preview 的用法

以前一直以為他不能在很多圖檔間捲動，原來其實是可以的！

動作就是先選擇要看的圖檔，類似漫畫之類的就直接 Cmd + A 全選，然後再 Double Click 就可以了。

旁邊會有抽屜拉出來，放置序列的縮圖，用 Cmd 搭配左右方向鍵可以在序列中前後移動。

VideoLAN 0.8.6b

在 Mac OS X 上 VideoLAN 是 MPlayer 以外另一個內建 codec 的開放原始碼影音播放器，新的版本跟之前我在用的時候比起來已經有很大的改進。

現在比較不會 crash 掉了，然後使用者界面上也比較好用。

Thunderbird 2

終於正式發行了。

新功能大概就是來自 Gmail 跟 Spotlight 的提示吧！對我這種小量使用者差別其實不是很大，不過看起來對於要處理大量信件者應該會蠻有幫助的。

官方網站: http://www.mozilla.com/thunderbird/

OpenOffice.org 2.2

一兩週前出了，主要是修正幾個安全問題，並且加強幾個元件的效率。

我自己是導入好一陣子了，沒什麼大問題，不過因為某種原因，現在主要是用 Calc 而已，不知道 Writer 狀況怎麼樣。

官方網站: http://www.openoffice.org/

MPlayer 1.0rc1 OSX PPC 上 ASS/SSA 字幕

似乎是因為 QuickTime 的 codec 在實作上難度相當高，倒不是難做，而是資料很不齊全，所以目前在 OS X 上比較受到討論的播放程式還是以 MPlayer 跟 VideoLAN 為主。這點算是蠻虧的，在 Windows 上有很多 codec 可以選擇，並且有各種實作，搭上 Media Player Classic 所有影片幾乎都可以播的很快樂，但是在 OS X 上就比較沒那麼精彩了。

之前用過 VideoLAN 感覺不是很好用，而且似乎不太穩定。同期也用過一個從 MPlayer 分支出來的 MPlayerOSX 不過老實說也有點怪怪的，常會自己掛掉。

本來 MPlayer 官方對於 OS X 的支援似乎是慢上一個世代，不過不知道是不是 Apple 最近開始猛攻中價位市場的關係，使得機器現在比較流行了，軟體支援就開始比較多些。總之，現在官方版的 MPlayer 在 OS X 的支援上跟其他平台是差不多一樣。

進入正題，重點在於要開啟 Play list 手動將字幕檔掛上影片檔，然後得要勾選 Preference 對話框下的 Miscellaneous 標籤頁中的 Additional Parameters 這個選項，並加入 -ass 的參數。這樣就會將所掛上的字幕識別為 ASS/SSA 格式，並正常的顯示出來。

不過在掛上字幕的對話框中，不能直接從檔案瀏覽器中選取 *.ass 的字幕檔，這是比較麻煩的事情。

買電腦要考慮的事情

除非我自己要買東西，順路，不然現在不太幫人買電腦了。不過還是會碰到一些朋友說要買新電腦，找我幫忙開規格這樣，這時候問題就來了，要買什麼樣的機器呢？

我個人是認為，現在自己裝電腦的話，說穿了就只有兩種選擇: 準系統 vs. 巨大桌上型電腦

準系統的好處是體積小，因為主機板小的關係，通常電力也會比較省一點，另外多半是以成為家電為目標，所以工業設計上也會比較講究；壞處就是擴充性相對較差，另外也得特別慎選系統廠，因為體積小的關係，散熱設計就變的很重要。

巨大桌上型電腦是最傳統的選擇，一般而言，缺點是體積大，笨重；好處就是擴充性較容易掌控，只要買對機殼就好了。

基本上，巨大桌上型電腦是可以滿足所有的應用，但是，以一般應用而言，我個人是偏向使用準系統，因為在整合度與空間利用上，準系統真的是方便很多。

進入正題，什麼情況下會適合使用準系統，什麼情況下不適合使用準系統呢？如果預期的使用情形是下面幾種，那麼還蠻適合使用準系統的:

• 主要是要用在上網路，處理文書、照片，看影片，聽音樂。
• 不是重度的電腦遊戲使用者，而且不特別追求遊戲的聲光效果。
• 不打算、不了解、不懂或是不會玩超頻之類動作。
• 不喜歡拆裝電腦。
• 前一台電腦使用超過兩年，期間不曾升級過中央處理器。
• 睡前通常會把電腦關掉

但是，如果你有下面幾項應用的話，那可能就不適合考慮使用準系統:

經常需要處理大量的影音資料

這比較會出現在剪接工作者上，因為準系統通常只能裝一臺內接式硬碟機，對剪接工作而言一台甚至兩台硬碟其實不太夠。

重度的 P2P 使用者

要用 P2P 的話，硬碟機也是內接兩台以上比較好。

經常的要玩 3D 遊戲

大多數的準系統可以接受額外的顯示卡，但是以 3D 遊戲而言，要一直保持在最佳效果的話，大概一年半就差不多得換不少東西，使用準系統的話可能不是很合算。

有一堆 PCI 卡要接

準系統大多數只有 1 到 2 條空的 PCI slot 可以使用。

需要 2G 以上的記憶體

準系統通常只有 2 條 DRAM 插槽，以目前比較平價的 1G 一條的記憶體模組而言，最多就是接到 2G 這樣。

基本上，主要就是差在是不是需要複數臺的內接式硬碟機，以及對升級的需求是不是非常頻繁。

準系統的素體會包含機殼、電源供應器以及主機版，如果要升級的話，一但要換到 CPU 那麼基本上準系統差不多就得整個換掉，因為換了 CPU 那麼通常主機版也得換了，而準系統的機殼跟板子通常是設計在一起的，所以機殼就得跟著換了。同時，電源供應器大多也會配合機殼設計，所以電源供應器也得換這樣。

以一般看電影、聽音樂、上網路的應用來講，主流的組態大概撐過 3 年應該不是問題，超過 3 年之後，零組件漸漸或多或少會開始出現老化所造成的毛病，速度可能也會不太趕的上當時的應用，這時候就算是巨大桌上型電腦，其實差不多也是除了機殼以外得整個換掉。

如果資料很重要的話，不論是什麼樣的電腦，都應該使用燒錄機或其他媒體備份重要資料出來。準系統的話也可以考慮買個外接式硬碟，資料量不多，或是只是暫時的要清出內接硬碟的空間時可以先堆在外接式硬碟上。

最後是預算上的問題，準系統一般來講會稍微貴一些，另外要添購外接硬碟的話，等級夠的外接盒的價位大概是在 2K ~ 4K 上下，對於預算很緊的人而言，準系統可能不是一個很好的選擇。

還有一些其他的問題，比如說外型夠不夠漂亮，規格是不是夠新，市場上的目前供貨狀況... 這就得自己跑賣場才有辦法了。

Firefox 微調

在設定上跟之前大致一樣，就是:

config.trim_on_minimize = true (boolean)

讓 Firefox 在視窗最小化時進行記憶體回收。

editor.singleLine.pasteNewlines = 3 (integer)

決定在將多行的文字貼到只有單行的輸入元件上時，把所有換行字元去除後全部貼上，這樣從 BBS 之類的東西上貼網址會比較方便。

network.http.pipelining = true (boolean)

啟動 HTTP pipelining 功能，這樣可以比較有效率的使用伺服器的運算速度。如果有使用 proxy 的話，那就也得把 network.http.proxy.pipelining 也設成 true 才行。

這個選項有個關聯選項: network.http.pipelining.maxrequests 預設值被設定在整數 4 這個值，文件上看來可以設定的範圍是等同於關閉 http pipelining 的 1 到最大的 8 之間的整數，個人是覺得不需要動這個值。

不過要注意的是，在某些受防火牆保護的網路之下，這個選項會讓連線被防火牆視為不正常的而使連線被阻斷，如果設定上去之後覺得網頁反應變慢了，可以把這個選項關了試試看。

browser.tabs.tabMinWidth = 60 (integer)

修改 tab 的最小寬度，螢幕不大的話改窄一點可以一次看到比較多的 tab 在上面。

capability.policy.default.Location.hostname.set = "noAccess" (string)

這個是安全性修正，主要是處理對 DOM 不完善的安全處理導致 Java Script 可以把本機端整個 cookies 檔偷走的問題。如果習慣使用論壇的「記住密碼」之類的一段時間免登入功能，那會受到影響。

至於 extension 方面，我主要是使用下面幾個:

All-in-One Gestures Extension

使用滑鼠手勢來控制部分動作，上手之後使用瀏覽器會更流暢快速。

adblock

過濾掉部分不要的網站內容，主要是又佔畫面空間而且讀取又慢的廣告。有些網站會一直跳 pop-up 視窗也可以用這個把跳視窗的 script 濾掉，開視窗佔時間。

Download Statusbar

可以把下載進度顯示到瀏覽器主視窗下方處，取代原本另外開 Download Window 的方式。感覺上是比較明瞭下載狀況，而且也可以不用在一堆視窗間換來換去。

Right Encoding

把網頁語系編碼切換的選單加到右鍵選單中，這樣比較方便，而且可以針對單一頁框進行設定。

Show Picture

在網路比較繁忙時，如果有臨時連不上造成的破圖，可以直接點選破圖讓 Firefox 試圖重新讀圖，不用整個頁面重新整理。之前是用 Show Image 來達到一樣的目的，不過似乎這個比較強大一點，而且看來比較有在維護。

Tempomail

取得一個暫時性的 e-mail 轉址，主要是對付利用註冊資料廣告的網站。

SwitchProxy Tool

切換 proxy 的工具，對於常要在幾個 proxy server 間切換的人蠻有用的。一個應用的例子是學術網路存取學術資料庫，有些學校位了防止對國外資料庫使用過度多的頻寬，所以限制一定要透過圖書館連資料庫，這時候有這個工具就很有用了。

Stop Autoplay

顧名思義，還蠻有用的。

livehttpheaders

可以擷取 HTTP 的協定資訊，對於網站的偵錯偶而會有點幫助。另外就是可以看看網頁到底拉了些什麼亂七八糟的東西下來，寫 spider 時還蠻有幫助的。

PasswordMaker

對於不擅長記一堆密碼的人蠻有用的工具，不過還是要小心 master key 被發現就是了，萬一被抓到就全都爆破了。

Download Them All

下載管理員，不過對於瀏覽器狀態的整合度其實沒有非常好。

Greasemonkey

可以自己撰寫 script 來重新安排特定網頁的內容，不過其實我自己是不常用。

Force Content-Type

覆寫由伺服器傳來的 MIME 模式，用在對付一些把未知檔案格式都當成 text/plain 的網站。

Google Notebook

Google 提供的服務之一，看到有興趣的網頁內容可以隨手記起來。

User Agent Switcher

切換瀏覽器送出的自我識別字串，主要是對付一些自以為很聰明把一些功能僅對某些特定瀏覽器開放的網站。不過這也不是萬靈丹就是，像 ActiveX 在 Firefox 上就不被支援，這邊騙過去了也沒用。另外，有些網站不是靠自我識別字串辨識瀏覽器，對於這種網站就沒有用了。

VirtualDub 1.7.1

新增了一些奇奇怪怪的功能，目前主要的新功能與改進大多都集中在影像擷取上，檔案壓縮的部分看來是接近飽和了吧！

或者，已經有 AviSynth 可以配合，所以就不用做進去了。

PuTTY 0.59

在前幾天 PuTTY 出了 0.59 版，比較受到我注意的有 Serial 連線能力。

然後也有提到一些 cipher 效能改善的修正，我自己是覺得可能是還好吧！因為現在電腦都很快，除非是跑 sftp/scp 不然單純用 ssh 的話可能感覺不太出來。

嗯，既然在 cipher 有變動的話，也許以 PuTTY 為基礎的 WinSCP 接下來也會更著更新也不一定。