Next: , Up: Managing Releases


7.1 設定がいかに働くべきか

各GNU配布物はconfigureという名前のシェル・スクリプトと一緒に配ら れるべきだ。このスクリプトにはそのプログラムをコンパイルしたいマシンやシス テムの種類を表す引数を与えられる。

configureスクリプトはコンパイルに効果を与えられるように設定オプショ ンを記録しなければならない。

これを行う一つの方法は、config.hのような標準的な名前から、選んだ システム用の適切な設定ファイルにリンクすることだ。これによって、人々はま ず設定しないとプログラムを構築できなくなるだろう。

configureが設定できる他の方法はMakefileを編集することだ。こうする なら、配布物はMakefileと名付けらたファイルを含むべきではない。 代わりに、編集に使われる入力を含むMakefile.inというファイルを入れ るべきだ。またもう一度、これはまず設定をしてないとプログラムを構築できな いようになるようにする。

もしconfigureMakefileに書き込むなら、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-feature[=parameter]
featureと呼ばれる付加的なユーザ水準の機能を構築しインストールする よう、パッケージを設定する。これで、ユーザはどの付加的な機能を入れるか選 択することができる。付加的なparameterに‘no’を与えれば、もしデ フォルトでは構築されるなら、featureを除くべきだ。

どの‘--enable’オプションも決してある機能を他と置き換えるべ きではない。どの‘--enable’オプションも決してある有用な挙動を他の有 用な挙動の代わりにするべきではない。‘--enable’の唯一の適切な使用は そのプログラムの一部を構築するか除くかの質問に対してだけだ。

--with-package
パッケージpackageがインストールされるだろうから、このパッケージが packageと一緒に働くように設定する。

packageの可能な値には、‘gnu-as’(あるいは‘gas’)、 ‘gnu-ld’、‘gnu-libc’、‘gdb’、‘x’、そして、 ‘x-toolkit’がある。

--with’オプションをあるファイルを見付けるためにファイル名を指定す るのに使ってはいけない。こういう使い方は‘--with’オプションの目的か ら外れている。

--nfp
ターゲット・マシンは浮動小数点プロセッサを持っていない。
--gas
ターゲット・マシンのアセンブラはGAS、つまり、GNUアセンブラである。これは もはや使われていない。ユーザは代わりに‘--with-gnu-as’を使うべきだ。
--x
ターゲット・マシンはX Window Systemをインストールしている。これはもはや 使われていない。ユーザは代わりに‘--with-x’を使うべきだ。

全てのconfigureスクリプトはこれらの“詳細な”オプションをすべて受 け入れるべきだ。それらが手もとの特定のパッケージに違いを作るかどうかにか かわらず。特に、それらは‘--with-’や‘--enable-’で始まるどんなオ プションでも受け入れるべきだ。これはユーザがオプション一組で一度にGNUソー ス・ツリー全体を設定できるするためだ。

--with-’や‘--enable-’の部類が狭いことに気付くだろう。それらは あなたが考えるようなオプションの類いに役目を果たさない。このこ とは計画的なのだ。我々はGNUソフトウェアで可能な設定オプションを制限した いのだ。我々はGNUプログラムに特異な設定オプションを持たせたくない。

コンパイルの過程の一部を行うパッケージはクロス・コンパイルをサポートする かもしれない。そういう場合、そのプログラムのホストとターゲットのマシンは 異なるかもしれない。configureスクリプトは通常指定されたシステムの 種類がホストとターゲットの両方だとして扱うべきだ。こうして、それが走るの と同じ種類のマシンで動くプログラムを作り出す。

クロス・コンパイラ、クロス・アセンブラ、あるいはあなたが持つどんなもので も、構築する方法は、configureを走らせるときに ‘--host=hosttype’というオプションを指定する。これはターゲッ ト・システムの種類を変えないでホスト・システムを指定する。hosttype の文法は上で述べたのと同じである1

クロス・コンパイラを開始するには、それが走るホスト以外のマシンでコンパイ ルすることが必要である。コンパイルされるパッケージは、あなたがそれらをコ ンパイルするシステムがホストとは異なる場合、設定を指定するために、 ‘--build=hosttype’という設定オプションを受け取る2

クロス作業は意味がないプログラムは、‘--host’オプションを受け取る必 要はない。なぜなら、クロス作業のためにオペレーティング・システム全体を設 定することは意味のあることではないからだ。

プログラムの中には自動的に自分自身を設定する方法を持っているものがある。 あなたのプログラムがこうするように作られていると、あなたの configureスクリプトはその引数のほとんどを無視して良い。


脚注

[1] 訳注: 嘘八百。この場合、 ‘--target=hosttype’を指定する。逆にホストの方を変えるとターゲッ トも変わる。詳しくはAutoconfのマニュアルを見よ。

[2] 訳 注: 原文のitはいまいち何を意味しているのか分からないが、内容から推測する に多分クロス・コンパイルされるパッケージかと思う。