從指令列開啟檔案

在 Linux 上很直觀的就是執行要開啟的程式來開檔案，不過也可以使用 xdg-open / gvfs-open / gnome-open 工具來透過 GNOME 開啟檔案。

在 MacOS 上則是用 open 工具，要指定開啟的 App 的話就是用 -a 選項這樣。

清除在 Finder 中「打開檔案的應用程式」裡重複出現的程式

成因不明，似乎跟 Launch Service 有關係。

在這裡看到解決方法，執行以下指令就可以解決了:

$ cd /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support
$ ./lsregister -kill -domain local -domain system -domain user

主要是要執行 lsregister 那個程式，在 10.6 上試過沒問題，似乎 10.5 程式的位置也在一樣的地方，再舊的版本好像是放在不同地方。

debian 上安裝基本的 GNOME 環境

在 debian 透過 tasksel 裝進來的 GNOME 環境不知道為什麼包了超多有的沒的東西，相當之傷腦筋... 但今天發現，可以只裝必須的部份就好了。

apt-get install gnome-core avahi-daemon p7zip synaptic system-config-printer hal-cups-utils

在 Linux 上編譯 Objective C 程式

套件的部份要加裝 gobjc 跟 gnustep-base-dev 兩個套件，後者包含 Foundation 等 Framework 檔案。

編譯時也很麻煩，要設定 inclusion path 跟 linking library 才可以。

gcc -lgnustep-base -lobjc -I /usr/include/GNUstep -fconstant-string-class=NSConstantString helloworld.m

把 Perl 模組裝在系統目錄以外的地方

流程其實蠻簡單的，在編譯模組第一步的 perl Makefile.PL 用 PREFIX=%TARGET_DIRECTORY% 作為參數即可。

perl Makefile.PL PREFIX=%TARGET_DIRECTORY%
make
make test
make install

然後設定環境變數 PERL5LIB 到所給定的 %TARGET_DIRECTORY% 下面的 share/perl 以及 lib/perl 之中，注意中間要使用冒號分隔。

export PERL5LIB=%TARGET_DIRECTORY%/share/perl:%TARGET_DIRECTORY%/lib/perl

除了 PERL5LIB 之外，也可以設定 PERLLIB 這個環境變數，不過 PERL5LIB 優先權比較高，而且這兩個變數是互斥的，換言之 Perl 會先找 PERL5LIB 這個環境變數是不是存在，如果沒有才去找 PERLLIB 環境變數。

在 Snow Leopard 下開啓 ls 的色彩化輸出

首先，給 bash 的設定要放在 ~/.bash_profile 裡頭，預設是沒有這個檔案的。因為透過 Terminal.app 啓動 bash 是透過 login 來作的，因此 ~/.bashrc 不會有作用。

在 ~/.bash_profile 裡面加上 export CLICOLOR=1 就可以啓動 ls 的 colorize output 了，要透過指令列開啓的話，則是使用 -G 選項，而不是在 GNU ls 下得 --color 選項。

常用的 Makefile 建置目標

3.3 The most useful Makefile targets / 常用的 Makefile 建置目標

By now `configure' has generated the output files such as a `Makefile'. Most projects include a `Makefile' with a basic set of well-known targets (see section 4.1 Targets and dependencies). A target is a name of a task that you want make to perform -- usually it is to build all of the programs belonging to your package (commonly known as the all target). From your build directory, the following commands are likely to work for a configured package:

截至目前為止，我們已經提到 `configure' 會產生一些輸出檔，比如 `Makefile' 檔案。大部分的專案會準備一個內建有常見建置目標的 `Makefile' 檔案 (請見 4.1 建置目標與相依性)。一個建置目標是一個你希望 make 幫你完成的工作的名稱 -- 比如，建置所有套件中的程式 (常見的 all 建置目標)。在已經完成套件組態的建置資料夾中，通常可以使用以下的指令:

make all

Builds all derived files sufficient to declare the package built.

建置出所有足使這個套件發揮功能的必要檔案。

make check

Runs any self-tests that the package may have.

執行在套件內所準備的自我測試程式。

make install

Installs the package in a predetermined location.

將套件檔案安裝到預先設定好的路徑中。

make clean

Removes all derived files.

刪除所有在建置過程中所產生的檔案。

There are other less commonly used targets which are likely to be recognized, particularly if the package includes a `Makefile' which conforms to the GNU `Makefile' standard or is generated by automake. You may wish to inspect the generated `Makefile' to see what other targets have been included.

還有一些比較少用到但是通常有支援的建置目標，特別是那些遵守了 GNU `Makefile' 標準或是由 automake 所產生的 `Makefile' 檔案。要知道所產生的 `Makefile' 支援了哪些建置目標，你可能需要看看所產生出來的 `Makefile' 檔案的內容。

從 Universal Binary 中移除非本機平台機械碼

以我的情況來說，在 PowerPC 平台上，執行檔中的 IA32/EM64T 的機械碼基本上是不需要的。在一些比較巨大的程式上，可以省下不少空間。

可以使用 ditto 這個內建的指令來從 Application Bundle 中移除非 PowerPC 機械碼:

ditto --rsrc --arch ppc /Applications/Camino.app /Applications/Camino-PPC.app

另一個相關的工具是 lipo 這個內建指令，不過他是用在 Mach-O binary 檔上的，不能直接給他 Application Bundle 資料夾去處理。

Git 的 push

之前是用 Subversion 來作版本控制，可是不是總是可以連到中央伺服器上，所以最近移轉到 Git 上。

Git 的 push 不會去改變 work copy 的內容，而且 HEAD 也不會前進到最新的 commit 上，一整個跟 Subversion 線性的歷史記錄不太一樣。

如果發生了 push 進附有 work copy 的 repository 的事情，更新 work copy 就得要先用 git log 先把最近一個 remote commit 的 commit ID 找出來，然後再用 git reset %COMMIT-ID% 來把 HEAD 設定過去，最後用 git checkout . 來把 work copy 更新。

看來還是要準備一個 bare repository 才行，也就是每個人要有 public repository 跟 private repository 兩個 repository ... 感覺實在挺浪費的。

建立 bare repository:

$ mkdir project.git
$ cd project.git
$ git init --bare

將現有位於 /home/me/project 的 repository 複製成位於 /home/me/repo/project.git 的 bare repository:

$ cd /home/me/repo
$ git clone --bare /home/me/project

把 remote repository 設定補進 private repository 中:

$ git remote add origin /home/me/repo/project.git
$ git config branch.master.remote origin
$ git config branch.master.merge refs/heads/master

在 OS X 上編譯 Subversion

因為 OpenCollabNet 提供的 OS X 映像檔在我的 10.4 PPC 上老是有名稱空間污染的毛病，單純用指令是沒問題，可是用 subclipse 就會有很大的問題，所以只好自己試試看重編一份，最差的情況就是下去 debug 看看到底是怎樣。

比想像中的順利的多，重新編譯就好了... 不用去改程式。

先把舊的 OpenCollabNet 版的資料夾改名，以避免編譯時去用到 OpenCollabNet 的 binary code 而造成相容性的問題。

sudo mv /opt/subversion /opt/subversion-154

要下載的是 subversion-1.5.5.tar.bz2 與 subversion-deps-1.5.5.tar.bz2 這兩個，後者提供了所需的第三方函示庫的原始碼，直接在同一個目錄下解壓兩者就可以了，檔案都會被解到 subversion-1.5.5 這個目錄之下。

tar -jxf subversion-1.5.5.tar.bz2
tar -jxf subversion-deps-1.5.5.tar.bz2
cd subversion-1.5.5/

在這篇提到可能會跑去找 jikes 這個比較老舊的東西來當 Java 編譯器，然後會因此編不出東西，所以要下 --with-jikes=no 把他關了，才會去用 javac 來編譯。

export CFLAGS="-g -O3"
export CXXFLAGS="-g -O3"
./configure --prefix=/opt/subversion --enable-javahl --with-jikes=no
make
make javahl
sudomake install
sudo make install-javahl

之前 OpenCollabNet 留下來的 symbolic link 之類的東西大致上都不需要動，可以沿用下來。所以就算是全新安裝，先裝看看 OpenCollabNet 版碰碰運氣也是不錯。

Perl binding 的部份則是要透過 SWIG 來編，也是要另外編譯與安裝。

make swig-pl
sudo make install-swig-pl

不過這邊安裝會裝到系統資料夾裡去，要自己把他們搬出來。

sudo mkdir /opt/subversion/lib/svn-perl
sudo mkdir /opt/subversion/lib/svn-perl/auto
sudo mv /Library/Perl/5.8.6/darwin-thread-multi-2level/SVN /opt/subversion/lib/svn-perl
sudo mv /Library/Perl/5.8.6/darwin-thread-multi-2level/auto/SVN /opt/subversion/lib/svn-perl/auto
sudo mv /usr/local/man/man3/SVN\:\:* /opt/subversion/share/man/man3/

修改 .profile 把 Perl Module 的目錄加到 PERL5LIB 這個環境變數裡，就可以讓 perl 找到。

export PERL5LIB=$PERL5LIB:/opt/subversion/lib/svn-perl/

Mac OS X 上更新 locate database

在 OS X 上要更新 locate 的 database 有兩個方法，一個是直接執行 /usr/libexec/locate.updatedb 這個更新用的指令稿，另一個是執行 /etc/periodic/weekly/500.weekly 或是長像類似的東西，後者是用來每週定期執行用的指令稿，有比較好的權限處理。

在 man locate 裡頭是說 /etc/periodic/weekly/310.locate 是定期執行用的指令稿，不過在我的機器上沒有這個檔案。

不管是執行哪個，可能都要利用 sudo 去執行，除非把資料庫檔案的權限改掉。

sudo /etc/periodic/weekly/500.weekly

由 configure 所產生的檔案

3.2 Files generated by configure / 由 configure 所產生的檔案

After you have invoked `configure', you will discover a number of generated files in your build tree. The build directory structure created by `configure' and the number of files will vary from package to package. Each of the generated files are described below and their relationships are shown in C. Generated File Dependencies:

在執行 `configure' 之後，你會發現有一些檔案在你的建置資料夾中被產生出來。在不同的套件中，由 `configure' 在建置資料夾所建立的資料夾結構以及檔案的數量會稍有不同。以下簡述所產生的檔案的功能，這些檔案間的關係則在 C. 所產出檔案間的相依性中描述:

`config.cache'

`configure' can cache the results of system tests that have been performed to speed up subsequent tests. This file contains the cache data and is a plain text file that can be hand-modified or removed if desired.

`configure' 可以藉由儲存系統測試程式的結果，來縮短後續測試所耗的時間。所儲存的快取資訊會以純文字的形式存放在這個檔案中，如果有需要的話，可以手動編修或移除這個檔案。

`config.log'

As `configure' runs, it outputs a message describing each test it performs and the result of each test. There is substantially more output produced by the shell and utilities that `configure' invokes, but it is hidden from the user to keep the output understandable. The output is instead redirected to `config.log'. This file is the first place to look when `configure' goes hay-wire or a test produces a nonsense result. A common scenario is that `configure', when run on a Solaris system, will tell you that it was unable to find a working C compiler. An examination of `config.log' will show that Solaris' default `/usr/ucb/cc' is a program that informs the user that the optional C compiler is not installed.

在 `configure' 執行時，會印出一些訊息來描述正在執行的測試，以及測試的結果。實際上，由 shell 以及 `configure' 所執行的工具程式會送出更多的訊息，但是為了讓印到輸出畫面的資訊較容易被使用者理解，這些額外的訊息不會被送到輸出畫面上。所有額外的訊息會被導向到 `config.log' 檔案中，當 `configure' 程式作出怪異的行為或是產生莫名奇妙的測試結果時，這個檔案是第一個該看看的地方。一個常見的例子是，在 Solaris 系統上執行 `configure' 時顯示找不到可以使用的編譯器的訊息。在檢視 `config.log' 後就會發現，在 Solaris 上所預先安裝的 `/usr/ucb/cc' 是一個顯示 C 編譯器尚未安裝的程式，並非是一個可用的編譯器。

`config.status'

`configure' generates a shell script called `config.status' that may be used to recreate the current configuration. That is, all generated files will be regenerated. This script can also be used to re-run `configure' if the `--recheck' option is given.

`configure' 會產生一個稱為 `config.status' 的 shell 指令稿，這個指令稿可以用來重新建立目前的組態環境。換言之，這個指令稿會重新產生所有 `configure' 所產生的檔案。另外，只要在執行時給定 `--recheck' 的選項，也可以透過這個指令稿來重新執行 `configure' 程式。

`config.h'

Many packages that use `configure' are written in C or C++. Some of the tests that `configure' runs involve examining variability in the C and C++ programming languages and implementations thereof. So that source code can programmatically deal with these differences, #define preprocessor directives can be optionally placed in a config header, usually called `config.h', as `configure' runs. Source files may then include the `config.h' file and act accordingly:

許多使用 `configure' 的套件是由 C 或 C++ 所撰寫的，有許多 `configure' 所執行的測試正是用來檢驗執行建置程序的 C/C++ 編譯器所提供的語言實作細節，以及檢驗諸如函式庫的版本或存在與否等編譯環境所提供支援的程度。測試所得的結果可以由 #define 前置處理指引的方式表現出來，通常會存放到檔名為 `config.h ' 的設定標頭檔中。在程式的原始碼中就可以引入 `config.h' 並且針對各個狀況來撰寫特定的程式碼片段分別處理，比如:

#if HAVE_CONFIG_H # include #endif /* HAVE_CONFIG_H */ #if HAVE_UNISTD_H # include #endif /* HAVE_UNISTD_H */

We recommend always using a config header.

我們建議所有的專案都應該使用設定標頭檔。

`Makefile'

One of the common functions of `configure' is to generate `Makefile's and other files. As it has been stressed, a `Makefile' is just a file often generated by `configure' from a corresponding input file (usually called `Makefile.in'). The following section will describe how you can use make to process this `Makefile'. There are other cases where generating files in this way can be helpful. For instance, a Java developer might wish to make use of a `defs.java' file generated from `defs.java.in'.

其中一個 `configure' 常被用到的功能是產生 `Makefile' 檔，或是其他有用的檔案。正如同之前所提到的，一個 `Makefile' 檔通常會是一個由 `configure' 分析一個對應的輸入檔 (通常會是 `Makefile.in') 所產生，接下來的章節會描述如何執行 make 來使用 `Makefile' 檔案。類似的方法也可以用在其他場合來產生有用的檔案，比如，一個 Java 程式設計師可能會想從一個 `defs.java.in' 來產生出 `defs.java' 檔。

進行組態

3.1 Configuring / 進行組態

A `configure' script takes a large number of command line options. The set of options can vary from one package to the next, although a number of basic options are always present. The available options can be discovered by running `configure' with the `--help' option. Although many of these options are esoteric, it's worthwhile knowing of their existence when configuring packages with special installation requirements. Each option will be briefly described below:

`configure' 指令稿接受一大堆的命令列選項，不同的套件所能夠接受的選項會不太一樣，有一些基本的選項在所有套件中都可以找到，各套件所可以接受的選項可以透過執行 `configure' 時加上 `--help' 選項取得。雖然有不少的選項通常不會被用到，但有特殊的需求時，知道一下這些選項的存在會很有幫助。以下簡述在所有套件中都能找到的基本選項:

`--cache-file=file'

`configure' runs tests on your system to determine the availability of features (or bugs!). The results of these tests can be stored in a cache file to speed up subsequent invocations of configure. The presence of a well primed cache file makes a big improvement when configuring a complex tree which has `configure' scripts in each subtree.

`configure' 會在你的系統執行測試程式以檢查系統所能提供的功能 (或是系統的錯誤與漏洞)，測試的結果會被存在一個快取檔案中，以縮短未來執行 configure 所耗用的時間。一些複雜的專案的原始碼樹在每個子資掉夾都有各自的 `configure' 指令稿，在這個情況下，可以透過留置快取檔案來大幅縮減組態所耗用的時間。

`--help'

Outputs a help message. Even experienced users of `configure' need to use `--help' occasionally, as complex projects will include additional options for per-project configuration. For example, `configure' in the GCC package allows you to control whether the GNU assembler will be built and used by GCC in preference to a vendor's assembler.

輸出說明訊息，因為一些複雜的專案會在 `configure' 中加入一些額外的選項，因此即使是有經驗的使用者偶而也需要使用 `--help' 選項。比如，在 GCC 套件的 `configure' 中就可以讓你控制是不是要建置 GNU 組譯器並讓 GCC 使用，或是要使用其他廠商所提供的組譯器。

`--no-create'

One of the primary functions of `configure' is to generate output files. This option prevents `configure' from generating such output files. You can think of this as a kind of dry run, although the cache will still be modified.

`configure' 的主要功能之一是產生用來建置套件的檔案，給定這個選項會讓 `configure' 不產生那些檔案，但快取檔仍會被修改，你可以將這個功能視為進行測試用的功能。

`--quiet'
`--silent'

As `configure' runs its tests, it outputs brief messages telling the user what the script is doing. This was done because `configure' can be slow. If there was no such output, the user would be left wondering what is happening. By using this option, you too can be left wondering!

在 `configure' 進行測試時，他會輸出一些簡單的訊息告訴使用者指令稿正在做什麼。因為 `configure' 的執行會花很多時間，如果沒有輸出這些東西，使用者只能在旁邊瞎猜現在的狀況。只要給定了這個選項，你就可以重新加入大家來瞎猜的行列。

`--version'

Prints the version of Autoconf that was used to generate the `configure' script.

印出產生這個 `configure' 指令稿的 Autoconf 版本。

`--prefix=prefix'

The --prefix option is one of the most frequently used. If generated `Makefile's choose to observe the argument you pass with this option, it is possible to entirely relocate the architecture-independent portion of a package when it is installed. For example, when installing a package like Emacs, the following command line will cause the Emacs Lisp files to be installed in `/opt/gnu/share':

--prefix 是經常被使用的一個選項，如果所產生的 `Makefile' 會嚴格遵守你隨著這個選項所傳入的參數，那麼就可以把整個套件中與硬體平台無關的部分安裝到預設路徑外的地方去。比如說，利用以下的指令安裝 Emacs 套件，會讓 Emacs 的 Lisp 檔案安裝到 `/opt/gnu/share' 之下:

$ ./configure --prefix=/opt/gnu

It is important to stress that this behavior is dependent on the generated files making use of this information. For developers writing these files, Automake simplifies this process a great deal. Automake is introduced in 7. Introducing GNU Automake.

很重要的一點是，所產生的檔案必須要會使用這項資訊。對於撰寫設定檔的開發者，使用 Automake 可以大幅簡化這個步驟，我們會在 7. GNU Automake 簡介中介紹 Automake。

`--exec-prefix=eprefix'

Similar to `--prefix', except that it sets the location of installed files which are architecture-dependent. The compiled `emacs' binary is such a file. If this option is not given, the default `exec-prefix' value inserted into generated files is set to the same value as the `prefix'.

這個選項與 `--prefix' 類似，但所指定的路徑位址是給與硬體平台相關的檔案使用的，比如所編譯出來的 `emacs' 執行檔。如果這個選項沒有給定，預設的 `exec-prefix' 值會被設定為 `prefix' 的值。

`--bindir=dir'

Specifies the location of installed binary files. While there may be other generated files which are binary in nature, binary files here are defined to be programs that are run directly by users.

給定要安裝執行檔的路徑位置，套件建置可能會產生很多各式各樣的執行檔，但這個選項所指的執行檔僅包含會被使用者直接執行的程式。

`--sbindir=dir'

Specifies the location of installed superuser binary files. These are programs which are usually only run by the superuser.

給定要安裝管理員用執行檔的路徑位置，這些程式通常只由系統管理員使用。

`--libexecdir=dir'

Specifies the location of installed executable support files. Contrasted with `binary files', these files are never run directly by users, but may be executed by the binary files mentioned above.

給定要安裝可執行的支援檔案的路徑位置，與上面所提及的 `執行檔' 所不同，被這個選項所指的檔案不會被使用者直接的執行，但可能會被上面所說的執行檔所執行。

`--datadir=dir'

Specifies the location of generic data files.

給定要安裝一般性的資料檔的路徑位置。

`--sysconfdir=dir'

Specifies the location of read-only data used on a single machine.

給定在單一機器上的設定資料的路徑位置，這些設定資料對一般使用者是唯讀的，且一般而言不同的機器會有不同的設定。

`--sharedstatedir=dir'

Specifies the location of data which may be modified, and which may be shared across several machines.

給定共用可讀寫資料的路徑位置，這些資料檔可以被使用者所更改，並且可能會在數臺不同的機器所共享。

`--localstatedir=dir'

Specifies the location of data which may be modified, but which is specific to a single machine.

給定專屬可讀寫資料的路徑位置，這些資料檔可以被使用者所更改，但只會由一臺機器存取使用。

`--libdir=dir'

Specifies where object code library should be installed.

給定安裝函式庫目的碼的路徑位置。

`--includedir=dir'

Specifies where C header files should be installed. Header files for other languages such as C++ may be installed here also.

給定安裝 C 標頭檔案的路徑位置，如 C++ 等其他語言所使用的標頭檔也可能會被安裝在這個選項所指定的路徑下。

`--oldincludedir=dir'

Specifies where C header files should be installed for compilers other than GCC.

給定安裝給非 GCC 的其他編譯器所使用的 C 標頭檔案的路徑位置。

`--infodir=dir'

Specifies where Info format documentation files should be installed. Info is the documentation format used by the GNU project.

給定安裝 Info 格式文件檔的路徑位置，Info 是被 GNU 計畫所使用的文件檔案格式。

`--mandir=dir'

Specifies where manual pages should be installed.

給定安裝使用手冊的路徑位置。

`--srcdir=dir'

This option does not affect installation. Instead, it tells `configure' where the source files may be found. It is normally not necessary to specify this, since the configure script is normally in the same directory as the source files.

這個選項不會影響到安裝，但可以裡用這個選項告訴 `configure' 套件原始碼所在位置。通常並不需要設定這個選項，因為 configure 指令稿通常會與原始碼放在一樣的資料夾內。

`--program-prefix=prefix'

Specifies a prefix which should be added to the name of a program when installing it. For example, using `--program-prefix=g' when configuring a program normally named `tar' will cause the installed program to be named `gtar' instead. As with the other installation options, this `configure' option only works if it is utilized by the `Makefile.in' file.

給定要在安裝個別執行檔時接到預設程式檔名之前的前置字串，比如，在組態 tar 套件時使用 `--program-prefix=g' 會讓正常情況下稱為 `tar' 的程式被更名為 `gtar'。就像其他的安裝選項，這個 `configure' 選項只在 `Makefile.in' 有使用到這個設定時才有效。

`--program-suffix=suffix'

Specifies a suffix which should be appended to the name of a program when installing it.

給定要在安裝個別執行檔時接到預設程式檔名之後的後置字串。

`--program-transform-name=program'

Here, program is a sed script. When a program is installed, its name will be run through `sed -e script' to produce the installed name.

在這裡的 program 是一個 sed 指令稿，在安裝個別執行檔時，預設的執行檔名會送進 `sed -e script' 以產生各執行檔的檔名。

`--build=build'

Specifies the type of system on which the package will be built. If not specified, the default will be the same configuration name as the host.

給定執行套件建置的系統平台名稱，如果這個選項沒有給定，預設將會使用與 host 相同的值。

`--host=host'

Specifies the type of system on which the package will run--or be hosted. If not specified, the host triplet is determined by executing `config.guess'.

給定將執行或安裝套件程式的系統平台名稱，如果這個選項沒有給定，預設將會執行 `config.guess' 來取得系統平台名稱。

`--target=target'

Specifies the type of system which the package is to be targeted to. This makes the most sense in the context of programming language tools like compilers and assemblers. If not specified, the default will be the same configuration name as the host.

給定套件的目標系統平台，這個選項在建置如編譯器或組譯器等程式語言工具時會較有意義。如果這個選項沒有給定，預設將會使用與 host 相同的值。

`--disable-feature'

Some packages may choose to provide compile-time configurability for large-scale options such as using the Kerberos authentication system or an experimental compiler optimization pass. If the default is to provide such features, they may be disabled with `--disable-feature', where feature is the feature's designated name. For example:

有些套件會讓使用者在編譯時期決定是不是要將像 Kerberos 認証系統之類較龐大的額外功能，或是實驗性的編譯時期最佳化選項納入建置。如果這些額外的功能預設是開啟的，那麼可以利用 `--disable-feature' 來將他們關閉，在這邊 feature 應代換為功能的代稱，例如:

$ ./configure --disable-gui

`--enable-feature[=arg]'

Conversely, some packages may provide features which are disabled by default. To enable them, use `--enable-feature', where feature is the feature's designated name. A feature may accept an optional argument. For example:

相反的，有些套件會將額外的功能預設為關閉。使用 `--enable-feature' 可以啟用這些額外的功能，在這邊 feature 應代換為功能的代稱。有些功能可以接受額外的參數，例如:

$ ./configure --enable-buffers=128

Using `--enable-feature=no' is synonymous with `--disable-feature', described above.

使用 `--enable-feature=no' 跟使用上面提到的 `--disable-feature' 會有相同的效果。

`--with-package[=arg]'

In the free software community, there is a healthy tendency to reuse existing packages and libraries where possible. At the time when a source tree is configured by `configure', it is possible to provide hints about other installed packages. For example, the BLT widget toolkit relies on Tcl and Tk. To configure BLT, it may be necessary to give `configure' some hints about where you have installed Tcl and Tk:

儘可能利用既有的套件與函式庫是自由軟體社群中一項健康的潮流，當利用 `configure' 對原始碼樹進行組態時，這個選項可以用來提供一些系統既有套件的資訊。例如 BLT widget toolkit 需要 Tcl 與 Tk 事先安裝在系統上，在組態時可能需要給 `configure' 一些關於 Tcl 與 Tk 安裝位置的提示:

$ ./configure --with-tcl=/usr/local --with-tk=/usr/local

Using `--with-package=no' is synonymous with `--without-package' which is described below.

使用 `--with-package=no' 與使用將在下面提到的 `--without-package' 會有相同的效果。

`--without-package'

Sometimes you may not want your package to inter-operate with some pre-existing package installed on your system. For example, you might not want your new compiler to use GNU ld. You can prevent this by using an option such as:

有時候你可能會不希望你建置的套件程式去使用系統內已安裝的套件，比如說，你可能不想讓新的編譯器使用 GNU ld 來連結程式。你可以用像下面這樣的選項來達到這個目的:

$ ./configure --without-gnu-ld

`--x-includes=dir'

This option is really a specific instance of a `--with-package' option. At the time when Autoconf was initially being developed, it was common to use `configure' to build programs to run on the X Window System as an alternative to Imake. The `--x-includes' option provides a way to guide the configure script to the directory containing the X11 header files.

這個選項其實是 `--with-package' 的一個特例。在 Autoconf 的開發初期, `configure' 常被用來作為 Imake 外的另一個建置 X Window System 應用程式的選擇。透過 `--x-includes' 選項，使用者可以告知 configure 指令稿 X11 的標頭檔所在的資料夾。

`--x-libraries=dir'

Similarly, the --x-libraries option provides a way to guide `configure' to the directory containing the X11 libraries.

與前項相似，透過 `--x-libraries' 選項，使用者可以告知 configure 指令稿 X11 函式庫檔所在的資料夾。

It is unnecessary, and often undesirable, to run `configure' from within the source tree. Instead, a well-written `Makefile' generated by `configure' will be able to build packages whose source files reside in another tree. The advantages of building derived files in a separate tree to the source code are fairly obvious: the derived files, such as object files, would clutter the source tree. This would also make it impossible to build those same object files on a different system or with a different configuration. Instead, it is recommended to use three trees: a source tree, a build tree and an install tree. Here is a closing example of how to build the GNU malloc package in this way:

在原始碼樹中執行 `configure' 是不必要也不被建議的，到原始碼樹之外的資料夾中執行 `configure' 來產生 `Makefile' 檔案並建置套件會比較好。在與原始碼樹分離的資料夾建置套件的優點是顯而易見的: 諸如目的檔等由建置程序所產生的檔案，將不會混雜到原始碼樹之中。此外，也可以在與原始碼樹分離的數個資料夾中分別進行建置動作，如此一來能讓一套原始碼可同時用來建置出給不同系統使用的執行檔，或是針對不同的組態分別進行建置作業。因此，我們建議的做法是在每次的建置作業中使用到三個不同的資料夾: 原始碼樹、建置資料夾以及安裝資料夾。以下是一個使用這個方法來建置 GNU malloc 套件的例子:

$ gtar zxf mmalloc-1.0.tar.gz $ mkdir build && cd build $ ../mmalloc-1.0/configure creating cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for a BSD compatible install... /usr/bin/install -c checking host system type... i586-pc-linux-gnu checking build system type... i586-pc-linux-gnu checking for ar... ar checking for ranlib... ranlib checking how to run the C preprocessor... gcc -E checking for unistd.h... yes checking for getpagesize... yes checking for working mmap... yes checking for limits.h... yes checking for stddef.h... yes updating cache ../config.cache creating ./config.status

Now that this build tree is configured, it is possible to go on and build the package and install it into the default location of `/usr/local':

現在，建置資料夾已經組態完成，接下來就可以使用以下指令來進行建置作業，並將成品安裝到預設的安裝資料夾 `/usr/local' 中:

$ make all && make install

關閉 Windows 檔案總管的影像檔案預覽功能

檔案預覽功能，主要就是滑鼠點在檔案上的時候，檔案總管會顯示影片或是圖片檔的縮圖在旁邊，底下的狀態列也會顯示諸如維度、彩色編碼模式、檔案註解等等資訊。

個人覺得是沒啥用的一個功能，而且電腦慢一點的話，在產生這些資訊的同時，諸如更名或是刪除等檔案操作都會因為檔案總管正在對檔案讀取以製作預覽而無法使用，得等個半天才能做檔案操作。

關閉圖片與影片的預覽可以使用下面這兩個指令:

regsvr32 /u shimgvw.dll
regsvr32 /u shmedia.dll

第一個指令會關閉圖片預覽，第二個指令則是關閉影片預覽。

要重新開啟圖片與影片的預覽則可以使用下面這兩個指令:

regsvr32 shimgvw.dll
regsvr32 shmedia.dll

同樣分別是針對圖片與影片發生作用，可以視情況擇一使用。

抽換掉 Fedora 9 網路安裝影像檔的核心

預設的影像檔內附的核心的網路驅動程式似乎是有問題，安裝到一半會發生 IRQ 處理異常，然後會整個停在那邊。

解決之道就是把核心換掉，不過換掉核心連帶的也得換掉驅動程式，所以不能單純的把 zImage 檔中核心的部分抽換，也要改 initrd 影像，用下面這個指令可以把 initrd 影像解出來。

objcopy -j .kernel:initrd -O binary zImage initrd.gz

接這就可以用 gzip 把影像檔解開得到 cpio 檔案，接著用下面這個指令解開 cpio 檔案。

cpio -idv < INPUT-FILE.cpio

把原本的 initrd 解開之後，找 anaconda 的 scripts/mk-images 來加以修改。重點在於執行 makemoduletree() 這個函式，可以參考 scripts/mk-images.ppc 來驅動 makeinitrd() 去執行 makemoduletree() 來產出 kernel object 的資料夾。

主要是把 /modules 的檔案都替換掉就沒有大問題了，接著在相當於 / 的檔案系統根目錄執行下面這個指令，來把檔案系統打包成 gzip 壓縮的 cpio 檔案。

find . | cpio --quiet -c -o | gzip --best > OUTPUT-FILE.initrd

給 Open Firmware 的 BOOTP 用的 zImage 檔基本上是 ELF32-BE 的格式的檔案，在 Fedora 7 的時候 kernel 會去找 .data 節區來作為 initrd 影像來源，不過在 Fedora 9 則是找 .kernel:initrd 這個節區。如果在 Fedora 7 上用 mkzimage 去做的話，開機的時候會當掉。

所以舊的給 Fedora 7 的 mkzimage 指令就不能用了，要找新的位於 kernel-bootwrapper 套件內的 wrapper 指令來用，單純解開來用的話要改一下 wrapper 裡的 $object 與 $objbin 這兩個變數，把他的內容指到解開套件的位置。

這部分我是這樣子改:

rootpath=%TEMP_WORKSPACE%
object=$rootpath/usr/lib64/kernel-wrapper
objbin=$rootpath/usr/sbin

OpenOffice.org 3.0 for MacOS

上次試用好像是 alpha 版本的時代吧！之前是使用 Neo Office 不過總是感覺有點頓，而且 2.2 的功能與界面有點粗，所以還是比較期待 3.0 的 Aqua native build 版本。

因為我的機器是 PowerPC 處理器，所以目前可以拿到的 pre-build binary 只有 RC4 版，據說幾乎就是 release 版了。

還是有點頓頓的，啟動仍是頗慢，檔案也是相當大！這個東西跟 Java 一樣都變成怪物了吧！比較好的是，比起 alpha 版超級無敵漫長的啟動時間並且動一下就當掉，現在的狀況已經改善很多。

nmap 是好物

今天要連某微型叢集內的某臺機器，不過因為整個不是我組態的，所以哪臺機器 IP 是多少我不太記得。

以前是自己臨場刻個 perl script 來掃，今天想一想還是找找看有啥工具。果然有個好物

nmap -sP 192.168.10.0/24

速度當然是比自己刻的快太多了，一下子就找到我要找的機器。

如何執行 configure 與 make

3. How to run configure and make / 如何執行 configure 與 make

A package constructed using Autoconf will come with a `configure' script. A user who wants to build and install the package must run this script in order to prepare their source tree in order to build it on their particular system. The actual build process is performed using the make program.

一個使用 Autoconf 建構的套件會含有一個 `configure' 指令稿，想要建置與安裝套件的使用者必須先執行這個指令稿，以針對使用者的系統調整所取得的原始碼樹。實際的建置程序，則是利用 make 程式來執行。

The `configure' script tests system features. For example, it might test whether the C library defines the time_t data type for use by the time() C library function. The `configure' script then makes the results of those tests available to the program while it is being built.

`configure' 指令稿會測試系統所支援的功能，舉例來說，他可能會測試 C 函式庫是不是定義了由 time() 這個 C 函式庫使用的 time_t 資料型別。完成測試後 `configure' 指令稿會把結果包裝成建置時期可以存取的型式，以供建置時使用。

This chapter explains how to invoke a `configure' script from the perspective of a user -- someone who just wants to take your package and compile it on their system with a minimum of fuss. It is because Autoconf works as well as it does that it is usually possible to build a package on any kind of machine with a simple configure; make command line. The topics covered in this chapter include how to invoke configure, the files that configure generates and the most useful `Makefile' targets -- actions that you want make to perform -- that will be available when compiling the package (see section 4. Introducing `Makefile's).

在這章，我們會從使用者 -- 也就是想在他自己的系統上取得你的套件並編譯，但不希望碰上大麻煩的那個人 -- 的角度來解釋怎麼執行 `configure' 指令稿。拜 Autoconf 的精良實作，我們通常可以在任何機器上執行簡單的 configure; make 指令來進行套件的建置。我們會在這章討論怎麼執行 configure，哪些檔案會被 configure 產生，以及一些在編譯套件時很有用的 `Makefile' 建置目標 -- 也就是你想要 make 進行的動作 (請參閱 4. 簡介 `Makefile')。

Microsoft Windows

2.6 Microsoft Windows / Microsoft Windows

In 1995, Microsoft released Windows 95, which soon became the most widely-used operating system in the world. Autoconf and Libtool were written to support portability across Unix variants, but they provided a framework to support portability to Windows as well. This made it possible for a program to support both Unix and Windows from a single source code base.

Microsoft 的 Windows 95 在 1995 年上市後，很快的變成世界上被廣泛使用的作業系統。 Autoconf 與 Libtool 除了提供在各種 Unix 分支版本的可攜性支援外，也提供了延伸可攜性支援到 Windows 上的程式設計框架，這使得透過單一份原始碼來同時支援 Unix 與 Windows 成為可能的事情。

The key requirement of both Autoconf and Libtool was the Unix shell. The GNU bash shell was ported to Windows as part of the Cygwin project, which was originally written by Steve Chamberlain. The Cygwin project implements the basic Unix API in Windows, making it possible to port Unix programs directly.

Autoconf 與 Libtool 都需要 Unix shell 程式，而 GNU bash shell 恰被作為 Cygwin 計畫的一部分移植到 Windows 上。 Cygwin 計畫是由 Steve Chamberlain 所發起的，這個計畫在 Windows 上實做了基本的 Unix API ，使得 Unix 程式可以直接的移植到 Windows 上。

Once the shell and the Unix make program (also provided by Cygwin) were available, it was possible to make Autoconf and Libtool support Windows directly, using either the Cygwin interface or the Visual C++ tools from Microsoft. This involved handling details like the different file extensions used by the different systems, as well as yet another set of shared library features. This first version of this work was by Ian Lance Taylor in 1998. Automake has also been ported to Windows. It requires Perl to be installed (see section A.1 Prerequisite tools).

在 shell 與 Unix 的 make 程式都被移植到 Windows 上之後，便可以讓 Autoconf 與 Libtool 透過 Cygwin 或是 Microsoft Visual C++ toolkit 直接的支援 Windows。增加 Windows 支援牽涉到處理一些在不同的作業系統上細節，例如處理不同的檔案延伸名稱以及額外的共享函式庫功能，第一個可以支援 Windows 的版本在 1998 年由 Ian Lance 所開發。除此之外 Automake 也被移植到 Windows 上，他需要 Perl 預先安裝在系統上 (參見 A.1 需預先安裝的工具) 。

處理 Fink 搭配 subclipse 找不到 JavaHL 的設定

Fink 安裝的位置是 /sw 目錄，不是一個非常公認的地方，所以預設的搜尋路徑是找不到要找的東西的。

修正方法有兩種，我是直接改到 eclipse.ini 裡去，並沒有另外弄個 wrapper script 來處理。

要加入的內容如下

-Djava.library.path=.:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:/sw/lib

前面一大串是預設直，在未作任何變動前應該可以從 About Eclipse Platform 的 Configuration 列表之中找到。