各GNU配布物はconfigure
という名前のシェル・スクリプトと一緒に配ら
れるべきだ。このスクリプトにはそのプログラムをコンパイルしたいマシンやシス
テムの種類を表す引数を与えられる。
configure
スクリプトはコンパイルに効果を与えられるように設定オプショ
ンを記録しなければならない。
これを行う一つの方法は、config.hのような標準的な名前から、選んだ システム用の適切な設定ファイルにリンクすることだ。これによって、人々はま ず設定しないとプログラムを構築できなくなるだろう。
configure
が設定できる他の方法はMakefileを編集することだ。こうする
なら、配布物はMakefileと名付けらたファイルを含むべきではない。
代わりに、編集に使われる入力を含むMakefile.inというファイルを入れ
るべきだ。またもう一度、これはまず設定をしてないとプログラムを構築できな
いようになるようにする。
もしconfigure
がMakefileに書き込むなら、Makefileは、
configure
が再び走り、最後に行ったのと同じ設定を作り上げる、
Makefileと名付けられたターゲットを持つべきだ。configure
が
読むファイルはMakefileの依存関係として列挙されているべきだ。
configure
スクリプトからの出力であるファイルはすべて、それらが
configure
を使って自動的に生成されたことを説明するコメントを先頭に
持っているべきだ。これによって、ユーザはそれらを手動で編集しようと考えな
くなるだろう。
configure
スクリプトは、プログラムが最後に設定されたときに指定され
た設定オプションを記述する、config.statusという名前のファイルを書
くべきである。このファイルはもし走ると同じ設定を再生成するシェル・スク
リプトであるべきだ。
configure
スクリプトは、(もし現在のディレクトリでなければ)ソー
スが見付かるディレクトリを指定するための`--srcdir=dirname'と
いう形式にオプションを受け取るべきだ。こうすると、プログラムを別ディレク
トリで構築することが可能なり、実際のソース・ディレクトリは変更されないよ
うにできる。
もしユーザが`--srcdir'を指定しなければ、configure
はソースが
見付かるかどうか見るのに、.と..の両方を確認するべきだ。も
しこれらの場所の一つでソースが見付かったら、そこからソースを使うべきだ。
そうでなければ、ソースが見付けられないと報告し、ゼロでない状態で終了する
べきだ。
普通`--srcdir'をサポートする簡単な方法はMakefileのVPATH
の定
義を編集することによる。これを可能にするために、configure
は
Makefileに正確に指定されたディレクトリの値を持つsrcdir
という名
前の変数を加えることができる。
configure
スクリプトはまたそのプログラムを構築するシステムの種類を
指定する引数を受け取るべきである。この引数は次のようであるべきだ。
cpu-company-system
例えば、Sun 3は`m68k-sun-sunos4.1'だ。
configure
スクリプトは、マシンを表す方法として、全てのもっともらし
い他の方法を解読できる必要がある。だから、`sun3-sunos4.1'は正しい別
名だろう。多くのプログラムでは、`vax-dec-ultrix'は
`vax-dec-bsd'の別名だろう。単にUltrixとBSDの違いはほとんど気付
かない程度だからだが、少数のプログラムはそれらを区別する必要があるかもし
れない。
サブルーチンとして使える、システムの種類を有効にし別名を正規化する、 config.subと呼ばれるシェル・スクリプトがある。
他のオプションで、そのマシンにあるソフトウェアやハードウェアをもっと詳細 に指定して良いし、パッケージの付加的な部分を入れたり、外したりして良い。
どの`--enable'オプションも決してある機能を他と置き換えるべ
きではない。どの`--enable'オプションも決してある有用な挙動を他の有
用な挙動の代わりにするべきではない。`--enable'の唯一の適切な使用は
そのプログラムの一部を構築するか除くかの質問に対してだけだ。
packageの可能な値には、`gnu-as'(あるいは`gas')、 `gnu-ld'、`gnu-libc'、`gdb'、`x'、そして、 `x-toolkit'がある。
`--with'オプションをあるファイルを見付けるためにファイル名を指定す
るのに使ってはいけない。こういう使い方は`--with'オプションの目的か
ら外れている。
全てのconfigure
スクリプトはこれらの“詳細な”オプションをすべて受
け入れるべきだ。それらが手もとの特定のパッケージに違いを作るかどうかにか
かわらず。特に、それらは`--with-'や`--enable-'で始まるどんなオ
プションでも受け入れるべきだ。これはユーザがオプション一組で一度にGNUソー
ス・ツリー全体を設定できるするためだ。
`--with-'や`--enable-'の部類が狭いことに気付くだろう。それらは あなたが考えるようなオプションの類いに役目を果たさない。このこ とは計画的なのだ。我々はGNUソフトウェアで可能な設定オプションを制限した いのだ。我々はGNUプログラムに特異な設定オプションを持たせたくない。
コンパイルの過程の一部を行うパッケージはクロス・コンパイルをサポートする
かもしれない。そういう場合、そのプログラムのホストとターゲットのマシンは
異なるかもしれない。configure
スクリプトは通常指定されたシステムの
種類がホストとターゲットの両方だとして扱うべきだ。こうして、それが走るの
と同じ種類のマシンで動くプログラムを作り出す。
クロス・コンパイラ、クロス・アセンブラ、あるいはあなたが持つどんなもので
も、構築する方法は、configure
を走らせるときに
`--host=hosttype'というオプションを指定する。これはターゲッ
ト・システムの種類を変えないでホスト・システムを指定する。hosttype
の文法は上で述べたのと同じである1。
クロス・コンパイラを開始するには、それが走るホスト以外のマシンでコンパイ ルすることが必要である。コンパイルされるパッケージは、あなたがそれらをコ ンパイルするシステムがホストとは異なる場合、設定を指定するために、 `--build=hosttype'という設定オプションを受け取る2。
クロス作業は意味がないプログラムは、`--host'オプションを受け取る必 要はない。なぜなら、クロス作業のためにオペレーティング・システム全体を設 定することは意味のあることではないからだ。
プログラムの中には自動的に自分自身を設定する方法を持っているものがある。
あなたのプログラムがこうするように作られていると、あなたの
configure
スクリプトはその引数のほとんどを無視して良い。