| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
リリースを行うことは、単にあなたのソースファイルをtarファイルに束ねてFTP に置くだけ以上のことである。あなたのソフトウェアを様々なシステムで走るよ うに設定できるように作り上げるべきだ。あなたのMakefileは以下で述べるGNU 標準に従うべきだし、あなたのディレクトリ設計も以下で記述されるGNU標準に 従うべきだ。そうすることで、あなたのパッケージを全てのGNUソフトウェアの より大きな骨組みに組み込むことが簡単になる。
| 7.1 設定がいかに働くべきか | ||
| 7.2 Makefileの取り決め | ||
| 7.3 リリースを行う |
各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
の文法は上で述べたのと同じである(6)。
クロス・コンパイラを開始するには、それが走るホスト以外のマシンでコンパイ ルすることが必要である。コンパイルされるパッケージは、あなたがそれらをコ ンパイルするシステムがホストとは異なる場合、設定を指定するために、 `--build=hosttype'という設定オプションを受け取る(7)。
クロス作業は意味がないプログラムは、`--host'オプションを受け取る必 要はない。なぜなら、クロス作業のためにオペレーティング・システム全体を設 定することは意味のあることではないからだ。
プログラムの中には自動的に自分自身を設定する方法を持っているものがある。
あなたのプログラムがこうするように作られていると、あなたの
configureスクリプトはその引数のほとんどを無視して良い。
この 節 では、GNUプログラムのMakefileを執筆するための慣例について記述する。
| 7.2.1 Makefileの一般的な慣例 | ||
| 7.2.2 Makefileのユーティリティ | ||
| 7.2.3 コマンド指定の変数 | ||
| 7.2.4 インストール命令の変数 | ||
| 7.2.5 ユーザ用の標準的なターゲット | ||
| 7.2.6 インストールのコマンドの部類 | `インストール'規則のコマンドの三つの部類: normal、pre-install、そしてpost-install。 |
あらゆるMakefileは次の行を含むべきだ。
SHELL = /bin/sh |
SHELL変数が環境から受け継がれるようなシステム上での問題を避けるた
めに。(これはGNU makeでは問題には決してならない。)
異なるmakeプログラムは互換性のない接尾辞のリストと暗黙の規則を持
ち、これはときどき混乱やおかしな挙動を生み出す。だから特定のMakefileで必
要とする接尾辞だけを使用するのに、明示的に接尾辞のリストを設定するのは良
い考えだ。
.SUFFIXES: .SUFFIXES: .c .o |
最初の行は接尾辞のリストを処分し、二番目はこのMakefileで暗黙の規則の対象 になるかもしれない接尾辞すべてを導入する。
`.'がコマンド実行のパスに入っていると仮定してはいけない。makeの間に あなたのパッケージの一部であるプログラムを走らせる必要があるとき、そのプ ログラムがmakeの一部として構築されるなら`./'を使い、もしファイルが ソース・コードの変更されない部分なら、`$(srcdir)/'を使うようにして ください。これらの接頭辞の一つを使わないと、現在の検索パスが使われる。
`./'(構築ディレクトリ)と`$(srcdir)/'(ソース・ディレ クトリ)の区別は、ユーザは`configure'に`--srcdir'オプションを 使って別のディレクトリで構築することができるので、重要である。次の書式の 規則は構築ディレクトリがソース・ディレクトリではないとき失敗する。 `foo.man'と`sedscript'はソース・ディレクトリの中にあるからだ。
foo.1 : foo.man sedscript
sed -e sedscript foo.man > foo.1
|
GNU makeを使うとき、ソースファイルを見付けるのに`VPATH'を頼
りにすることは、単一の依存関係ファイルがある場合には上手く行くだろう。
makeの自動変数`$<'は、ソースファイルがどこにあっても、それを
表すから。(makeのたくさんのバージョンは暗黙的規則でだけ`$<'
を設定する。)
foo.o : bar.c
$(CC) -I. -I$(srcdir) $(CFLAGS) -c bar.c -o foo.o
|
このようなMakefileのターゲットは代わりに次のように書かれるべきだ。
foo.o : bar.c
$(CC) -I. -I$(srcdir) $(CFLAGS) -c $< -o $@
|
`VPATH'が正しく働くようにするために。ターゲットが複数の依存関係を持 つとき、明示的な`$(srcdir)'を使うことがその規則を上手く働かせる一番 簡単な方法だ。例えば、`foo.1'に対するターゲットは次のように書かれて るのが一番良い。
foo.1 : foo.man sedscript
sed -e $(srcdir)/sedscript $(srcdir)/foo.man > $@
|
GNUの配布物は普通ソースファイルではない、いくつかのファイルを含む。---例 えば、InfoファイルやAutoconf、Automake、BisonやFlexからの出力だ。これら のファイルは通常ソース・ディレクトリに現れるので、それらは構築ディレクト リではなく、常にソース・ディレクトリに現れるべきだ。だからそれらを更新す るMakefileの規則はソース・ディレクトリに更新されたファイルを置くべきだ。
しかしながら、もしファイルが配布物に現れないなら、Makefileはソース・ディ レクトリにそれを置くべきではない。なぜなら、普通の環境でプログラムを構築 することで、どんな方法でもソース・ディレクトリを変更するべきではないから だ。
構築とインストールのターゲットを少なくとも(そしてそれらのサブターゲッ
ト全てが)並列makeで正しく働くように試みなさい。
Makefileのコマンド(そしてconfigureのようなシェル・スクリプト)を、
cshではなく、shで走るように書きなさい。kshや
bashの特別な機能を一切使ってはいけない。
configureスクリプトと構築とインストールのためのMakefileの規則は次
のものを除いて、どんなユーティリティも直接使うべきではない。
cat cmp cp diff echo egrep expr false grep install-info ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch true |
圧縮プログラムのgzipはdist規則で使って良い。
これらのプログラムに対して、一般的にサポートされているオプションを守りな さい。例えば、あったら便利な、`mkdir -p'はほとんどのシステムでサポー トしていないので使ってはいけない。
少数のシステムではサポートしていないので、makefileではシンボリック・リン クを作らないようにするのは良い考えだ。
構築とインストールのためのMakefileの規則はまたコンパイラや関連したプログ
ラムを使っていいが、ユーザが代わりのものと換えられるようにmake変
数を通して使うべきだ。我々が言っているプログラムをここでいくつか挙げる。
ar bison cc flex install ld ldconfig lex make makeinfo ranlib texi2dvi yacc |
これらのプログラムを走らせるのに次のmake変数を使いなさい。
$(AR) $(BISON) $(CC) $(FLEX) $(INSTALL) $(LD) $(LDCONFIG) $(LEX) $(MAKE) $(MAKEINFO) $(RANLIB) $(TEXI2DVI) $(YACC) |
ranlibやldconfigを使うとき、システムが当のプログラムを持っ
ていなくても悪いことが何も起きないようにするべきだ。そのコマンドからのエ
ラーを無視するように調整し、そのコマンドの前にユーザにこのコマンドの失敗
が問題ではないことを伝えるメッセージを出力しなさい。(Autoconfの
`AC_PROG_RANLIB'マクロはこれを助けることができる。)
もしシンボリック・リンクを使うなら、シンボリック・リンクを持たないシステ ム用に別手段を実装するべきだ。
Make変数を通して使って良い別のユーティリティには次のものがある。
chgrp chmod chown mknod |
他のユーティリティを使うことは、あなたがそれらのユーティリティが存在する と知っている特定のシステムのためだけに、Makefileの一部(やスクリプト)が意 図されているなら使って良い。
Makefileはあるコマンドやオプションなどを上書きするために変数を提供するべ きだ。
とりわけ、ほとんどのユーティリティ・プログラムを変数を通して走らせるべき
だ。だから、もしBisonを使うなら、BISONと名付けられた、そのデフォ
ルトの値が`BISON = bison'と設定されている変数を持ち、Bisonを使う必
要があるときにはいつでも$(BISON)を使ってそれを参照しなさい。
ln、rm、mvなどなどのようなファイル管理ユーティリティ
はこのやり方の変数を通した参照をする必要はない。ユーザはそれらを他のプロ
グラムと置き換える必要がないので。
それぞれのプログラム名変数は、プログラムにオプションを与えるのに使われる
オプション変数と一緒に使われるべきだ。オプション変数の名前を得るのにプロ
グラム名変数の名前に`FLAGS'を付け加えなさい。---例えば、
BISONFLAGSのように。(Cコンパイラに対するCFLAGS、yaccに対す
るYFLAGS、lexに対するLFLAGSの名前はこの規則には例外的だが、
我々はそれらは標準的なのでそうしておく。) プリプロセッサを走らせるどのコ
ンパイルのコマンドでもCPPFLAGSを使い、ldの直接的な使用だけ
ではなく、リンクを行うどのコンパイルのコマンドでもLDFLAGSを使いな
さい。
もしあるファイルの適切なコンパイルに使われなければならないCコンパ
イラのオプションがあれば、CFLAGSにそれらを入れてはいけない。ユー
ザはCFLAGSを自分で自由に指定できると期待する。代わりに、
CFLAGSとは独立に必要なオプションをCコンパイラに渡すように調整しな
さい。次のように、それらを明示的にコンパイルのコマンドに書くか、暗黙の規
則を定義することによって。
CFLAGS = -g
ALL_CFLAGS = -I. $(CFLAGS)
.c.o:
$(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $<
|
`-g'オプションをCFLAGSに入れなさい。なぜなら、それは適切なコ
ンパイルには必要ではないからだ。それを単に推奨されるデフォルトで
あると考えることができる。もしパッケージがデフォルトでGCCでコンパイルさ
れるように設定されているなら、CFLAGSのデフォルトの値に`-O'も
入れてもいい。
ユーザが他を上書きするのにCFLAGSを使うことができるので、
CFLAGSをコンパイルのコマンドの最後、コンパイラのオプションを含む
他の変数の後に置きなさい。
CFLAGSは、コンパイルを行うのとリンクを行う両方の、Cコンパイラのあ
らゆる起動で使われるべきだ。
あらゆるMakefileはINSTALLという変数を定義するべきで、それはファイ
ルをシステムにインストールするための基本的なコマンドである。
あらゆるMakefileはまたINSTALL_PROGRAMとINSTALL_DATAという
変数を定義するべきだ。(これらは各々デフォルトは$(INSTALL)であるべ
きだ。) そして、これらの変数を実際のインストールのコマンドとして、それぞ
れ実行ファイルと実行ファイルでないものに対して使うべきだ。これらの変数は
次のように使いなさい。
$(INSTALL_PROGRAM) foo $(bindir)/foo $(INSTALL_DATA) libfoo.a $(libdir)/libfoo.a |
インストールのコマンドの二番目の引数として、ディレクトリ名ではなく、常に ファイル名を使いなさい。インストールされるそれぞれのファイルに対して、別々 のコマンドを使いなさい。
インストール命令は常に変数によって名前が付けられているべきだ。だから、標 準的でない場所にインストールするのは簡単である。これらの変数の標準的な名 前は以下で述べる。それらは標準的なファイルシステムの構造に基いている。そ れに似たものがSVR4、4.4BSD、Linux、Ultrix v4や他の現代的なオペレーティン グ・システムで使われている。
これらの二つの変数はインストールのためのルートを設定する。他のインストー ル命令はすべてこれら二つのうちの一つのサブディレクトリであるべきで、これ ら二つのディレクトリへ直接インストールされるものがあるべきではない。
prefixのデフォルトの値は`/usr/local'であるべきだ。完全なGNU
システムを構築するとき、接頭辞は空で、`/usr'は`/'へのシンボリッ
ク・リンクになるだろう。(もしAutoconfを使っているなら、それを
`@prefix@'と書きなさい。)
exec_prefixのデフォルトの値は$(prefix)であるべきだ。(もし
Autoconfを使っているなら、それを`@exec_prefix@'と書きなさい。)
一般的に、$(exec_prefix)は(実行ファイルやサブルーチン・ライブラリ
のような)マシンに特定のファイルを含むディレクトリに対して使われるが、
$(prefix)は他のディレクトリに対して直接使われる。
実行プログラムは以下のディレクトリの一つにインストールされる。
実行中にプログラムによって使われるデータ・ファイルは二つの方法の部類に分 けられる。
これは6つの異なる可能性をもたらす。しかしながら、我々は、オブジェクト・ ファイルやライブラリは別にして、アーキテクチャ依存のファイルの使用をやめ させたい。他のデータ・ファイルをアーキテクチャ非依存にすることはずっとき れいで、普通は困難ではない。
それゆえ、ここにMakefileがディレクトリを指定するのに使うべき変数を挙げる。
このディレクトリに実行ファイルをインストールしてはいけない(それらおそら く`$(libexecdir)'か`$(sbindir)'に属する)。また、普通の方針で使っ ているときに変更するファイルはインストールしてはいけない(システムの設定 を変更するための目的のプログラムは除く)。それらはおそらく `$(localstatedir)'に属する。
libdirの値は普通
`/usr/local/lib'だが、それを`$(exec_prefix)/lib'と書きなさい。
(もしAutoconfを使っているなら、それを`@libdir@'と書きなさい。)
もしAutoconfを使っているなら、デフォルトを`@lispdir@'と書きなさい。 `@lispdir@'が働くようにするために、`configure.in'ファイルに 以下の行が必要である。
lispdir='${datadir}/emacs/site-lisp'
AC_SUBST(lispdir)
|
GCC以外のほとんどのコンパイラは`/usr/local/include'ディレクトリのヘッ
ダ・ファイルを探さない。だからこの方法でヘッダ・ファイルをインストールす
ることはGCCにだけ役に立つ。一部のライブラリはGCCで働くことだけを本当に意
図しているので、これは時には問題ではない。しかし一部のライブラリは他のコ
ンパイラと働くことを意図している。それらはヘッダ・ファイルを二つの場所、
includedirに指定されるところとoldincludedirに指定されると
ころにインストールするべきだ。
Makefileのコマンドはoldincludedirの値が空かどうか確認すべきだ。も
しそうなら、それを使おうとするべきではない。ヘッダ・ファイルの二番目のイ
ンストールを取りやめるべきだ。
パッケージはこのディレクトリにすでにあるヘッダを、そのヘッダが同じパッケー
ジに由来しているのでないなら、置き換えるべきではない。だから、もしあなた
のFooパッケージがヘッダ・ファイルの`foo.h'を提供するなら、もし、
(1)`foo.h'がないか、(2)すでにある`foo.h'がFooパッケージ由来か、
のどちらかなら、oldincludedirディレクトリにそのヘッダ・ファイルを
インストールするべきだ。
`foo.h'がFooパッケージ由来かどうかを見分けるために、そのファイルに
魔法の文字列---コメントの一部---を置き、その文字列をgrepしなさい。
Unix形式のmanページは次のうちの一つにインストールされる。
どんなGNUソフトウェアの主要な解説書もmanページにしてはならない。 代わりにTexinfoでマニュアルを書きなさい。manページは単にUnix上でGNUソフ トウェアを走らせる人々のためだけで、それは副次的なアプリケーションだけだ。
そして最後に、以下の変数を設定するべきだ。
configure
シェル・スクリプトによって挿入される。(もしAutoconfを使っているなら、
`srcdir = @srcdir@'を使いなさい。)
例。
# Common prefix for installation directories. # NOTE: This directory must exist when you start the install. prefix = /usr/local exec_prefix = $(prefix) # Where to put the executable for the command `gcc'. bindir = $(exec_prefix)/bin # Where to put the directories used by the compiler. libexecdir = $(exec_prefix)/libexec # Where to put the Info files. infodir = $(prefix)/info |
もしあなたのプログラムが標準的なユーザ指定のディレクトリに、非常にたくさ
んのファイルをインストールするなら、このプログラムに特定のサブディレクト
リにそれらをまとめると有用かもしれない。もしこうするなら、これらのサブディ
レクトリを作るためのinstall規則を書くべきだ。
上に挙げたどの変数の値にも、ユーザがサブディレクトリの名前を含めると期待し てはいけない。インストール・ディレクトリのための変数名の一組を持つという 考えは、ユーザがいくつかの異なるGNUパッケージに正確に同じ値を指定できる ようにすることである。これを有用なものとするために、あらゆるパッケージは ユーザがそうするときに賢く働くように設計されなければならない。
全てのGNUプログラムはそれらのMakefileに以下のターゲットを持つべきだ。
デフォルトでは、Makeの規則は`-g'付きでコンパイルしリンクするべきだ。 こうして実行プログラムはデバッグのシンボルを持つ。無力なことを気にしない ユーザは、彼らが望むなら、その実行ファイルを後でstripすることができる。
実行ファイルをインストールするときにstripしてはいけない。向こう見ずなユー
ザはそうするためにinstall-stripターゲットを使うことができる。
もし可能なら、`make all'が終わっていたら、そのプログラムが構築され
たディレクトリのどんなものも変更しないようにinstallターゲットの規
則を書きなさい。これはあるユーザ名でプログラムを構築し、他のユーザ名でそ
れをインストールするのに便利である。
そのコマンドはファイルがインストールされるディレクトリを、もしまだなかっ
たら、全て作成するべきである。これは必要とされるサブディレクトリ全てだけ
でなく、変数prefixやexec_prefixの値で指定されるディレクト
リも含む。これを行う一つの方法は以下で述べるようなinstalldirsター
ゲットを使うことによる。
manページをインストールためのどんなコマンドの前にも、makeがどんな
エラーも無視するように、`-'を使いなさい。これはUnixのmanページ解説
システムがインストールされてないシステムの場合である。
Infoファイルをインストールする方法は、それらを$(INSTALL_DATA)
(see section 7.2.3 コマンド指定の変数)で`$(infodir)'に複製することで、もしあれ
ば、install-infoプログラムを走らせる。install-infoは与えら
れたInfoファイルのメニュー項目を加えたり更新したりするためにInfoの
`dir'ファイルを編集するプログラムである。それはTexinfoパッケージの
一部だ。ここでInfoファイルをインストールする見本の規則を挙げる。
$(infodir)/foo.info: foo.info
$(POST_INSTALL)
# There may be a newer info file in . than in srcdir.
-if test -f foo.info; then d=.; \
else d=$(srcdir); fi; \
$(INSTALL_DATA) $$d/foo.info $@; \
# Run install-info only if it exists.
# Use `if' instead of just prepending `-' to the
# line so we notice real errors from install-info.
# We use `$(SHELL) -c' because some shells do not
# fail gracefully when there is an unknown command.
if $(SHELL) -c 'install-info --version' \
>/dev/null 2>&1; then \
install-info --dir-file=$(infodir)/dir \
$(infodir)/foo.info; \
else true; fi
|
installターゲットを書くとき、三つの部類に全てのコマンドを分類しな
ければならない。普通のものと、pre-installationコマンドと
post-installationコマンドだ。See section 7.2.6 インストールのコマンドの部類。
この規則はコンパイルが行われたディレクトリを変更せず、ファイルがインストー ルされるディレクトリだけを変更するべきだ。
アンインストールのコマンドはインストールのコマンドと同様、三つの部類に分 けられる。See section 7.2.6 インストールのコマンドの部類。
installに似ているが、実行ファイルをインストールする間にそれらを
stripする。多くの場合、このターゲットの定義は非常に単純で良い。
install-strip:
$(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \
install
|
通常我々は、あなたがそのプログラムにバグがないと確信しているのでないなら、 実行ファイルをstripすることを推奨しない。しかしながら、バグがある場合用 にstripしていない実行ファイルを別のところに保存して、実際の実行用にstrip された実行ファイルをインストールすることは理に適っていることもあり得る。
現在のディレクトリから、普通プログラムを構築することによって作られた全て のファイルを削除する。設定を記録するファイルは削除してはいけない。また、 構築によって作ることができても、配布物から手に入るので普通は作らないファ イルは残しておきなさい。
もし配布物の一部でないなら、`.dvi'ファイルは削除しなさい。
distcleanによって削除される全てのものと、さら
に、Bisonによって生み出されたCのソース・ファイル、タグの表、Infoファイル
などなどを含む。
"ほとんど全て"と言う理由は、コマンド`make maintainer-clean'を走ら
せることで、例え`configure'はMakefileの規則を使って再生できたとして
も、`configure'を削除するべきでないということだ。もっと一般的に、
`make maintainer-clean'は`configure'を走らせるために、そしてプ
ログラムを構築し始めるために存在する必要があるどんなものも削除するべきで
はない。これが唯一の例外だ。maintainer-cleanは再構築される得る他
のものは全て削除するべきだ。
`maintainer-clean'ターゲットは、普通のユーザではなく、そのパッケー ジの管理者によって使われることが意図されている。`make maintainer-clean'が削除するファイルの一部を復元するために、特別なツール を必要とするかもしれない。これらのファイルは普通配布物に含められるので、 それらが簡単に復元することは気にしない。もし全配布物を再び展開する必要が あることを見出しても、我々を非難してはいけない。
ユーザがこれに気付くのを助けるために、特別なmaintainer-cleanター
ゲットのためのコマンドはこれら二つで始まるべきだ。
@echo 'This command is intended for maintainers to use; it' @echo 'deletes files that may need special tools to rebuild.' |
info: foo.info
foo.info: foo.texi chap1.texi chap2.texi
$(MAKEINFO) $(srcdir)/foo.texi
|
MakefileにMAKEINFOという変数を定義してなければならない。それは
makeinfoプログラムを走らせるべきで、それはTexinfo配布物の一部であ
る。
普通、GNU配布物はInfoファイルと一緒に手に入り、このことはInfoファイルが ソース・ディレクトリにあることを意味する。それゆえ、infoファイルのための Makeの規則はソース・ディレクトリでそれを更新するべきだ。ユーザがそのパッ ケージを構築するとき、普通のMakeはInfoファイルを更新しないだろう。なぜな ら、それらはすでに最新だろうから。
dvi: foo.dvi
foo.dvi: foo.texi chap1.texi chap2.texi
$(TEXI2DVI) $(srcdir)/foo.texi
|
MakefileにTEXI2DVIという変数を定義してなければならない。それは
texi2dviというプログラムを走らせるべきで、それはTexinfo配布物の一
部である。(8) あるいは、単に依存
関係だけを書き、GNU makeがそのコマンドを提供できるようにしなさい。
例えば、GCCのバージョン1.40の配布用tarファイルは`gcc-1.40'と名付け られたサブディレクトリに展開する。
これを行う一番簡単な方法は適切に名付けられたサブディレクトリを作り、
lnかcpでそれに適当なファイルをインストールし、そのサブディ
レクトリにtarすることである。
そのtarファイルをgzipで圧縮しなさい。例えば、GCCのバージョン1.40
の実際の配布ファイルは`gcc-1.40.tar.gz'と名付けられている。
配布物にあるソースではないファイル全てを配布物中で最新にしておくために、
distターゲットは明示的にそれらに依存すべきだ。
See section Making Releases.
以下のターゲットは、それらが有用であるプログラムに対して、慣習的な名前を 提案している。
installcheck
installdirs
# Make sure all installation directories (e.g. $(bindir))
# actually exist by making them if necessary.
installdirs: mkinstalldirs
$(srcdir)/mkinstalldirs $(bindir) $(datadir) \
$(libdir) $(infodir) \
$(mandir)
|
この規則はコンパイルがなされるディレクトリを変更するべきではない。インス トール用のディレクトリを作成する以外に何もするべきではない。
installターゲットを書くとき、三つの部類にそのコマンド全てを分類し
なければならない。普通のものと、pre-installationコマンドと、
post-installationコマンドに。
普通のコマンドは適切な場所にファイルを移動し、それらのモードを設定する。 それらはどんなファイルも、完全にそれらが属するパッケージから手に入るもの を除いて、変化させないのが良い。
pre-installationとpost-installationのコマンドは他のファイルを変えても良 い。特に、それらは大域的な設定ファイルやデータベースを編集して良い。
pre-installationコマンドは典型的には普通のコマンドの前に実行され、 post-installationコマンドは典型的には普通のコマンドの後に走らされる。
post-installationコマンドの最も普通の利用はinstall-infoを走らせる
ことである。これは普通のコマンドでは行われ得ない。それは、完全には、そし
てインストールされるパッケージだけからは手に入らないファイル(Infoディレ
クトリ)を変化させる。それはパッケージのInfoファイルをインストールする普
通のコマンドの後に行われる必要があるのでpost-installationコマンドである。
ほとんどのプログラムはpre-installationコマンドを必要としないが、我々はそ れが必要とされる場合にだけその機能を持つ。
install規則のコマンドをこれら三つの部類に分類するために、それらの
中に部類行を挿入しなさい。部類行は次のコマンドの部類を指定する。
部類行はタブと特別なMake変数への参照に加えて、最後に付加的なコメントから 成る。それぞれの部類に対して一つ、使うことができる三つの変数がある。変数 名は部類を指定する。部類行は、これら三つのMake変数は普通未定義(そして、 それらをmakefileで定義するべきではない)ので、普通の実行では何も行 わない。
ここで、それぞれそれが何を意味するのか説明するコメントと共に、その三つの あり得る部類行を挙げる。
$(PRE_INSTALL) # Pre-install commands follow.
$(POST_INSTALL) # Post-install commands follow.
$(NORMAL_INSTALL) # Normal commands follow.
|
もしinstall規則の始めに部類行を使わないなら、全てのコマンドは、最
初の部類行まで普通のものと分類される。もしどの部類行も使わないなら、全て
のコマンドは普通のものと分類される。
これらはuninstallのための部類行である。
$(PRE_UNINSTALL) # Pre-uninstall commands follow.
$(POST_UNINSTALL) # Post-uninstall commands follow.
$(NORMAL_UNINSTALL) # Normal commands follow.
|
典型的には、pre-uninstallコマンドはInfoディレクトリから項目を削除するた めに使われるだろう。
もしinstallやuninstallターゲットがインストールのサブルーチ
ンとして振る舞う依存関係を持つなら、それぞれの依存関係のコマンド
を部類行で始めるべきで、主要なターゲットのコマンドも部類行で始めるべきだ。
こうして、それぞれのコマンドが、依存関係のそれが実際に走るかどうかに関係
なく、正しい部類に位置するように保証できる。
pre-installationとpost-installationのコマンドはこれら以外のプログラムを 走らせるべきではない。
[ basename bash cat chgrp chmod chown cmp cp dd diff echo egrep expand expr false fgrep find getopt grep gunzip gzip hostname install install-info kill ldconfig ln ls md5sum mkdir mkfifo mknod mv printenv pwd rm rmdir sed sort tee test touch true uname xargs yes |
この方法でコマンドを区別する理由はバイナリ・パッケージを作るためである。 典型的にはバイナリ・パッケージは全ての実行ファイルとインストールされる必 要がある他のファイルを含み、それらをインストールする、それ自身の方法を持 つ---だから、それは普通のインストールのコマンドを走らせる必要がない。し かし、バイナリ・パッケージをインストールすることはpre-installationと post-installationのコマンドを走らせることを必要とする。
バイナリ・パッケージを構築するためのプログラムはpre-installationと post-installationのコマンドを抜粋することによって働く。ここで pre-installationコマンドを抜粋する一つの方法を示す。
make -n install -o all \
PRE_INSTALL=pre-install \
POST_INSTALL=post-install \
NORMAL_INSTALL=normal-install \
| gawk -f pre-install.awk
|
ここで`pre-install.awk'というファイルは次のものを含む。
$0 ~ /^\t[ \t]*(normal_install|post_install)[ \t]*$/ {on = 0}
on {print $0}
$0 ~ /^\t[ \t]*pre_install[ \t]*$/ {on = 1}
|
pre-installationコマンドの結果生じるファイルはバイナリ・パッケージをイン ストールすることの一部として、シェル・スクリプトとして実行される。
Foo version 69.96の配布物を`foo-69.96.tar.gz'という名前で
gzipされたtarファイルにまとめなさい。それは`foo-69.96'という名前の
サブディレクトリに展開されるべきだ。
そのプログラムの構築やインストールは配布物に含まれるどのファイルも決して 変更するべきではない。これは、どんな方法でもプログラムの一部を作るファイル は全て、ソースファイルとソースでないファイルに分類されていな ければならないことを意味する。ソースファイルは人間によって書かれ、自動的 には決して変更されない。ソースでないファイルはMakefileの管理の下に、プロ グラムによってソースファイルから生成される。
配布物は、パッケージの名前とそれが何をするのか一般的な記述を与える、 `README'という名前のファイルを含むべきだ。また、もしあるなら、パッ ケージの一番上にあるサブディレクトリそれぞれの目的を説明するのも良い。 `README'ファイルはパッケージのバージョン・ナンバーを記述するか、そ れが見付かるパッケージ内の場所を参照するべきだ。
`README'ファイルは`INSTALL'というファイルを参照すべきだ。それ はインストールのやり方の説明を含むべきだ。
`README'ファイルはまた著作物の条件を含むファイルを参照するべきだ。 もし使われていれば、GNU GPLは`COPYING'と呼ばれるファイルにあるべき だ。もしGNU LGPLが使われているなら、それは`COPYING.LIB'と呼ばれるファ イルにあるべきだ。
当然ソースファイルは全部配布物になければならない。ソースでないファイ
ルを配布物に入れても構わない。もしそれらが最新状態でマシンに依存しておら
ず、配布物は通常それらを変更することがあり得ないのなら。我々は普通Bison、
lex、TeX、そしてmakeinfoによって生成されたソースでない
ファイルを含めている。これは、ユーザがインストールしたいパッケージではど
れでもインストールできるので、我々の配布物間での不必要な依存関係を避ける
のに役立っている。
プログラムを構築したりインストールすることによって実際に変更されるかもし れないソースでないファイルは、絶対に配布物に入れるべきではない。 だからもしソースでないファイルを配布するなら、新しい配布物を作るとき、そ れらを常に最新にしておきなさい。
配布物が展開するディレクトリは(どのサブディレクトリも)全て誰でも書き込み
可能にしておきなさい(8進数モードの777)。これは、tarアーカイブのファイル
の所有者と許可を保存する、tarの古いバージョンがそのユーザが特権的
でない場合でも全てのファイルを展開できるようにするためだ。
配布物の全てのファイルは誰でも読み込み可能にしておきなさい。
配布物の中にファイル名が14文字より長いものがないようにしておきなさい。同 様に、そのプログラムを構築することによって出来るファイルはどれも14文字よ り長い名前を持たないようにするべきだ。これの理由は一部のシステムは POSIX標準の馬鹿げた解釈に固執し、過去にやっていたように長い名前を切 り詰めるよりも開くことを拒んでいるからだ。
配布物それ自体にシンボリック・リンクを含めてはいけない。tarファイルがシ ンボリック・リンクを含むなら、人々はシンボリック・リンクをサポートしない システム上ではそれを展開することさえできない。また、異なるディレクトリで 一つのファイルに複数の名前を使ってはいけない。なぜなら、あるファイルシス テムはこれを扱えないし、このことは配布物を展開できなくするからだ。
全てのファイル名がMS-DOS上で重ならないようにしてみなさい。MS-DOSでの名前 は8文字以下から成り立ち、付加的にピリオドと3文字以下の文字がくっつく。 MS-DOSは余分な文字をピリオドの前と後両方で切り詰めるだろう。だから、 `foobarhacker.c'と`foobarhacker.o'は曖昧でない。それらは `foobarha.c'と`foobarha.o'に切り詰められ、それらは区別できる。
あなたの配布物に`*.texinfo'や`*.texi'ファイルの出力を試験する のに使った`texinfo.tex'のコピーを入れなさい。
同様に、もしあなたのプログラムがregex、getopt、obstack、あるいはtermcap のような小さなGNUソフトウェア・パッケージを使うなら、配布物にそれらを含 めなさい。それらを省くと、その配布ファイルはちょっと小さくなるが、他のファ イルをどうやって手に入れるか分からないユーザにいくらか不便になるという犠 牲を払うことになる。
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |