裝電腦或修電腦這件事

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

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

裝電腦

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

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

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

至於建議的牌子，桌上型的話: 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 的說明。