| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ソフトウェアをリリースするということは,単にソースファイルを tar ファイルに まとめて FTP サイトに置くだけでは済みません.そのソフトウェアの設定を 色々なシステムで動作するように構成可能にする必要があります. Makefile は,以下に述べるように GNU コーディング規約に則っている 必要がありますし,ディレクトリ構造も以下で議論するようになっている 必要があります.そうすることで,すべての GNU ソフトウェアからなる フレームワークにそのパッケージを取り込むことが容易になります.
7.1 どのようにコンフィギュレーションを行うか 7.2 Makefileの規約 7.3 リリース
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GNU の配布物には configure というファイル名のシェルスクリプトを
入れておく必要があります.
このスクリプトには, 計算機やシステムの種類を記述する引数を指定します.
configure スクリプトはコンフィギュレーションの
オプションを記録して,コンパイルの際に反映されるようにしなければ
なりません.
そのための方法の一つは, `config.h'のような標準的な名前を, システム固有のコンフィギュレーションファイルにリンクすることです. この方法を使うなら, 配布物には `config.h' を 含めてはいけません. これは, configure を実行しないうちは, プログラムを構築できないようにするためです.
configure に Makefile を編集させることもできます. その場合,
配布物には `Makefile' という名前のファイルを含めないで
ください. その代わりに, 編集に必要な入力の入ったファイル
`Makefile.in' を含めるべきです.
これも, configure を実行しないうちはプログラムを構築できないように
するためです.
configure が `Makefile'を作るならば, `Makefile' の中に
`Makefile' というターゲットが書かれていなければなりません.
このターゲットは, configure を再起動し, 最後に設定された
コンフィギュレーションをもう一度再設定します.
configure が読み込むファイルは ターゲット `Makefile'
の依存ファイルとして列記されてなければなりません.
configure スクリプトが出力するファイルには, 全て先頭にコメントを
入れ, configureから自動生成されたことの説明を付けておきます.
これはユーザが自分で書き直そうとしないようにするためです.
configure スクリプトは `config.status'というファイルを作成し,
プログラムが最後に構成された時の指定オプションを記録しなければなりません.
このファイルはシェルスクリプトになるようにし,
実行すると同じ構成を再設定するようにしなければなりません.
configure スクリプトは, ソースの存在するディレクトリ
（それがカレントディレクトリでないなら）を指定するオプション
`--srcdir=dirname' を受け付けなければなりません.
このオプションを指定すれば, 実際のソースディレクトリを変更せずに,別の
ディレクトリにプログラムを作ることが可能になります.
ユーザが `--srcdir 'を指定しない場合, configure は,
ソースが存在するかどうか,
`.' と `..'を調べる必要があります. もしどちらかに
存在すればそこにあるソースを使うようにし,
見つからなければソースがないと報告してゼロ以外のステータスで終了しなければ
なりません.
`--srcdir' をサポートする簡単な方法は, Makefile 中の VPATH の定義
を編集することです.(makeの)ルールの中には, 指定されたソースディレクトリを
明示的に参照することが必要なものがあります.
これを可能にするため, configure は Makefile に
srcdir という名の変数を追加できます.
この変数の値は指定されたソースディレクトリです.
configure は,プログラムを構築するシステムのタイプを決めるための引数を
受け付けます.その引数は次のような形式です.
cpu-company-system |
たとえば Sun 3 ならば `m68k-sun-sunos4.1'となります.
configure は, 計算機を記述するための適当な別名を
解読できる必要があります.
つまり, `sun3-sunos4.1' は, 有効な別名になるようにしなければなりません.
Ultrix と BSD の違いはほとんど気づかないものだし,それを区別する
必要のあるプログラムも滅多にないので,多くのプログラムに
とっては `vax-dec-ultrix' は `vax-dec-bsd' の別名となり得ます.
`config.sub'というスクリプトがあります. これはシステムのタイプと 正規化された別名を確認するためのサブルーチンとして使えます.
各マシン上のソフトウェア,ハードウェアをもっと詳細に指定したり, パッケージ中のオプション部分を取り込むか,外すかを指定する オプションを与えることができます.
`--enable' オプションを指定することで,一つの機能を何か別のもう一つの 機能で置き換えてはいけない. `--enable' オプションを指定する ことで,一つの便利な動作を他の便利な動作の代用にしてはいけない. `--enable' の正しい使い道はただ一つで,プログラムの一部を構築するか それとも排除するかを選ぶためにある.
configureは以上の詳細なオプションを全て受け付なければいけません.それが
特定のパッケージに違いをもたらすものであろうとなかろうと.
特に, `--with-' あるいは `--enable-'で始まるオプションは,
１つのオプションのセットで
GNU のソース・ツリー全体を同時に構成できるようにするために,
必ず受け付けなければなりません.
`--with-' と `--enable-' の役割は限られたものであることに 注意してください.読者が自分で思い付いたオプションを置く場所では ありません.つまり,慎重に考えてください. 我々は, GNU ソフトウェアでは指定できるコンフィギュレーションの オプションを限定したいのです.GNU のプログラムに変なコンフィギュレーション オプションを入れたくないのです.
コンパイルの過程の一部をなすようなパッケージは, クロスコンパイルをサポート する可能性があります. そのような場合, ホストとターゲットマシンは異なるものに指定できます.
通常は, configure は指定されたシステムのタイプをホストとターゲット両方に
対してのものと見なすので, 同じタイプのマシンで動くプログラムを作成します.
クロスコンパイラ, クロスアセンブラ等をコンフィギュレーションするには,
configure を実行する時に
ホストとはことなるターゲットを,
`--target=targettype' オプションを使って指定します.
targettype の書き方は上に述べたとおりです.
つまり,コマンド行は以下のようになります.
./configure hosttype --target=targettype |
クロス環境で動かすことに意味のないプログラムの場合には, `--target' オプションを受け付ける必要はありません. 何故なら,クロスで動くオペレーティングシステム 全体を構成することは意味のないことだからです.
クロスコンパイラをブートストラップするには, ホスト以外の, その コンパイラが走るであろうマシン上で,それをコンパイルする必要があります. コンパイラパッケージは,コンフィグレーションオプション `--build=buildtype' で, コンパイルを行なう コンフィグレーションを指定することができます. ただし,configure スクリプトは通常,構築を行なう機種型を(`config.guess' を使って)推測するはずなので,このオプションはおそらく必要ないでしょう. ホストとターゲットの機種のデフォルトは通常ビルド機種になるので, クロスコンパイラをブートストラップする場合は,両方を明示的に 指定しなければなりません.
自分自身を自動的に構成するプログラムもあります.
自分のプログラムがそのように設定されていれば,
configure スクリプトはその引数のほとんどを単に無視できるでしょう.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
この ノード では GNU のプログラムに向けて Makefile を書くときの規約を述べます. Automake を使うと、以下の規約に従う Makefile を書く助けとなります。
: ノーマル、プレインストール、ポストインストール
7.2.1 Makefileについての一般的な規約 7.2.2 Makefile 中で使用するユーティリティ 7.2.3 コマンドを指定するための変数 7.2.4 インストールディレクトリ 7.2.5 標準的なターゲット 7.2.6 インストールコマンドのカテゴリ `install'の規則のコマンドの三つのカテゴリ
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
変数 SHELL が環境変数から継承される可能性のあるシステムでの
問題を避けるために, Makefile には必ず以下の一行が必要です.
（これは, GNU make では決して問題になりません.）
SHELL = /bin/sh |
make によっては,サフィックスのリストや暗黙のルールについて
互換でない部分があるために,混乱や誤解を招くことが良くあります.
ですから,問題の Makefile で必要なサフィックスだけを明示的に
サフィックスのリストに設定するのが良い方法です.例えば
以下のように書きます.
.SUFFIXES: .SUFFIXES: .c .o |
一行目でサフィックスリストをクリアしておき,二行目でこの Makefile の 中で暗黙のルールに従って欲しいサフィックスを定義します.
コマンド検索パスの中には必ずしも `.' が入っているとは限りません. make の実行時にパッケージに含まれるプログラムを起動する必要がある場合, そのプログラムが make で作成されるものならば `./'を, あるいはそのファイルがソースコードの不変な部分であるときは, `$(srcdir)/' を使っているかを確かめてください. これらの接頭辞（prefix）がなければ現在の検索パスが使われます.
`./'(コンパイルディレクトリ と `$(srcdir)/'(ソースディレクトリ) の区別は重要です. 何故なら、`configure' の `--srcdir' オプションを使って 別のディレクトリでコンパイル可能でなければならないからです。
foo.1 : foo.man sedscript
sed -e sedscript foo.man > foo.1
|
と言う形のルールは, コンパイルディレクトリがソースディレクトリと異なる場合, `foo.man' と `sedscript' はソースディレクトリにあるので 失敗します.
GNU make を使う場合に,
依存ファイルが一つしかない場合は,ソースファイルを見つける手段として
`VPATH'を使うとうまくいきます.なぜならば,ソースファイルがどこに
あっても make の組み込み変数 `$<' でそれを表現できるからです.
(多くの make では, `$<' は暗黙のルールでのみ設定されます.)
Makefileのターゲットは,
foo.o : bar.c
$(CC) -I. -I$(srcdir) $(CFLAGS) -c bar.c -o foo.o
|
ではなく, `VPATH' が正しく働くように,次のように書くべきです.
foo.o : bar.c
$(CC) -I. -I$(srcdir) $(CFLAGS) -c $< -o $@
|
ターゲットが複数のファイルに依存している場合は, 明示的に `$(srcdir)' を 使うのが, 最も簡単にルールを機能させる方法です. 例えば, 上の foo.1 というターゲットは次のように書くのが一番良いでしょう.
foo.1 : foo.man sedscript
sed -e $(srcdir)/sedscript $(srcdir)/foo.man > $@
|
GNU の配布物には通常、ソースファイルではないファイル---例えば、Info ファイルや Autoconf, Automake, Bison, Flex 等の出力ファイルが含まれています。 これらのファイルは通常はソースディレクトリに置かれるので、 必ずコンパイルディレクトリではなくてソースディレクトリに置かれるように する必要があります。つまり、Makefile の書き方としては、 これらのファイルを更新するときにはソースディレクトリに更新されたファイルを 置くようにする必要があります。
一方、あるファイルが配布物には含まれないものなら、Makefile では、 それをソースディレクトリに置くように書いてはいけません。なぜなら、 通常の環境でプログラムをコンパイルするときには、ソースディレクトリを 更新すべきではないからです。
少なくとも構築用とインストール用のターゲットについては
(そして,それらのサブターゲット全てについても),並列 make を
使用した場合にも正しく動作するようにしましょう.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 中のその特別なシステム向けの部分（あるいはスクリプト）に記述するのは 構いません.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Makefileでは,ある種のコマンドやオプションなどを上書きするための変数を 提供しなければなりません.
特に,大部分のユーティリティプログラムは変数を経由させて起動すべきです.
つまり, Bisonを使う必要があるなら BISONという変数を設けてその
デフォルト値を `BISON = bison' とし,必要な箇所で
は $(BISON) と書いて参照するようにします.
ln, rm, mv などのファイル管理ユーティリティは
このように変数経由にしなくてかまいません.
これらを他のプログラムに置き換える必要がないからです.
プログラム名を指定するための変数ごとに,そのプログラムにオプションを
与えるための
オプション変数を設けましょう.オプション変数の名前は,プログラム名の変数名に
`FLAGS'をつけたものにします.例えば BISONFLAGSとします.
（C コンパイラ用の CFLAGS, yacc 用の YFLAGS, lex 用の
LFLAGS はこの規則の例外ですが,すでに標準になっているのでそのままに
します.）
プリプロセッサを起動するコマンドには CPPFLAGSを,
リンクを行なうコマンドには, ld コマンドを直接使う時と同様に
LDFLAGS を使います.
特定のファイルだけ特別な方法でコンパイルするときに必要になる
Cコンパイラのオプションは, CFLAGSには入れないでください.
ユーザは自分で自由に 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_PROGRAM のデフォルト値は $(INSTALL) で、
INSTALL_DATA のデフォルト値は ${INSTALL} -m 664 で
なければなりません。）
実際には, これらの変数で指定されるコマンドを使って,それぞれ実行形式ファイル,
非実行形式ファイルをインストールします.
次のように使用します.
$(INSTALL_PROGRAM) foo $(bindir)/foo $(INSTALL_DATA) libfoo.a $(libdir)/libfoo.a |
あるいは、DESTDIR の値をターゲットのファイル名の頭に付ける
こともできます。こうしておくと、インストーラが、実際の目標の
ファイルシステムに後でコピーできるような、インストールのスナップショットを
作ることが出来るようになります。Makefile で DESTDIR の値を
設定しないこと。また、インストールされるファイルにそれを含めないこと。
DESTDIR のサポートを追加すると、上の例は次のようになる。
$(INSTALL_PROGRAM) foo $(DESTDIR)$(bindir)/foo $(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a |
インストールコマンドの第二引数には,ディレクトリ名でなく,ファイル名を指定する ようにします.一つのコマンドで,一個のファイルをインストールするようにします.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
インストール先のディレクトリ名は必ず変数で与えなければなりません. そうしておけば標準的でない場所にインストールするのが容易になります. 変数の名前を以下に示します.これらは標準的なファイルシステム構成 に基づくものです.これに似たものが SVR4, 4.4BSD, GNU/Linux, Ultrix v4 等の 最近のオペレーティングシステムで使われています.
最初の二つの変数は,インストールのトップディレクトリを設定します. 他の全てのインストールディレクトリは,このどちらかのサブディレクトリ でなければなりません.また,この二つのディレクトリには何も 直接インストールしてはいけません.
prefix
prefixのデフォルト値は `/usr/local' でなければならない.
完全な GNU システムを構築する際には,このプレフィックスは空で,
`/usr' は, `/' へのシンボリックリンクとなる予定である.
(Autoconf を使うなら, `@prefix@' と書く.)
プログラムを構築するときに使った prefix の値と
異なる値を使って `make install' を実行した場合、
そのプログラムを再コンパイルすべきではない。
exec_prefix
exec_prefix のデフォルト値は $(prefix) でなければならない.
(Autoconf を使うなら, `@exec_prefix@' と書く.)
一般的に, $(exec_prefix) は計算機に固有のファイル
（実行形式ファイルやライブラリ）を置くディレクトリに使われる.
一方, $(prefix)はその他のディレクトリ用に直接使われる.
プログラムを構築するときに使った exec_prefix の値と
異なる値を使って `make install' を実行した場合、
そのプログラムを再コンパイルすべきではない。
実行可能プログラムは,以下のディレクトリのどれか一つにインストール されます.
bindir
sbindir
libexecdir
プログラムが実行中に使用するデータファイルには,二つの分類方法があります.
以上のことから,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で指定する.
#includeヘッダファイルを置くディレクトリ.
これは通常 `/usr/include'である.
(Autoconf を使うのなら, `@oldincludedir@' と書く.)
Makefile 中のコマンドは, oldincludedirが空でないかどうかチェックしな
ければならない.もし空なら,使ってはいけない.
ヘッダファイルの二番目のインストールはやめるべきである.
各（ソフトウェア）パッケージは,同じパッケージが提供したものでない限り,
このディレクトリにすでに存在しているヘッダーを置き換えるべきではない.
つまり,Foo というパッケージが `foo.h' というヘッダーファイルを
提供している場合, このヘッダーファイルを
oldincludedir ディレクトリにインストールするのは,
次のどちらかの場合だけにすべきである.
(1) `foo.h' がそのディレクトリにない場合,(2) パッケージ Foo が
提供した `foo.h' が存在する場合.
`foo.h' が Foo というパッケージから来たのものかどうかが分かるように,
ファイルの中に,コメントの一部として特別な文字列を埋め込んでおいて,
grep コマンドで調べるようにする.
Unix 形式のマンページは以下のどこかにインストールします.
GNUソフトウェアの主なドキュメントはマンページにしてはいけない. かわりにTexinfoで書くこと.マンページは GNUソフトウェアを Unix で動かす人々の ためにあり,それは二義的な目的にすぎないから.
そして最後に,以下の変数を設定する必要があります.
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 パッケージに対しても 全く同じ値を指定できるようにするためです. この決まりが役に立つためには,全てのパッケージは, ユーザがそうした時に正しく動くように設計しなくてはなりません.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GNU プログラムの Makefile には以下のターゲットを入れなければなりません.
デフォルトでは,このターゲットのルールはコンパイルとリンクに `-g' オプションを使って,実行形式にデバッグ情報を入れる必要がある. デバッグ情報が無くても困らないユーザは,後で実行形式をストリップすれば 良いのである.
インストール時に実行形式をストリップしてはならない.
デバッグ情報がいらないユーザ向けに install-strip というターゲット
がある.
可能ならば, installターゲットに対応するルールは
プログラムを構築したディレクトリは何もいじらず, `make all'
を実行した直後の状態になるように書きましょう.
こうすると,プログラムの構築とインストールを別の人が行うのが
簡単になります.
ファイルをインストールすべきディレクトリが既に存在していなければ,
それらのディレクトリを全て作らなければならない.
これは,必要な全てのサブディレクトリだけではなく,変数 prefix と
exec_prefix の値で指定されるディレクトリを含む.
このための一つの方法として,後述する installdirs ターゲットによる
方法がある.
マンページ（man page）をインストールするコマンドには必ず先頭にも
`-' をつけて, make がエラーを無視するようにすること.
これは Unix マンページシステムがインストールされてないシステムに
備えるためである.
Info ファイルをインストールするには,それらを $(INSTALL_DATA)
(see section 7.2.3 コマンドを指定するための変数) を使って, `$(infodir)' にコピーし,
その後, install-info プログラムがあればそれを実行する.
install-info は,Info の `dir' ファイルを編集し,
指定した Info ファイルのメニューエントリを追加,更新するプログラムである.
これは, Texinfo パッケージの一部である.
以下に Info ファイルをインストールするルールの例を示す.
$(DESTDIR)$(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 $(DESTDIR)$@; \
# 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=$(DESTDIR)$(infodir)/dir \
$(DESTDIR)$(infodir)/foo.info; \
else true; fi
|
install ターゲットを書くときには、そこで使用するコマンドを
全て三つのカテゴリに分類する必要があります。それは、ノーマルと
プレインストールとポストインストールです。
See section 7.2.6 インストールコマンドのカテゴリ.
このルールでは,コンパイルを行ったディレクトリを触ってはならない. ファイルをインストールしたディレクトリのみを更新すべきである.
アンインストールコマンドも,インストールコマンドと同様三つのカテゴリに 分けられる. See section 7.2.6 インストールコマンドのカテゴリ.
install と同じ.ただし,インストールする際に実行形式ファイルを
ストリップする. 単純な場合, このターゲットは install ターゲットを
使って以下のように簡単にできる。
install-strip:
$(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \
install
|
ただし、パッケージが本当の実行形式だけでなくスクリプトも
インストールする場合は、install-strip ターゲットが
単に install ターゲットを参照することはできない。
実行形式はストリップしなければならないが、スクリプトはしては
ならない。
install-strip はインストールの際のコピー元になる、
構築ディレクトリにある実行形式をストリップすべきではない。
インストールされたコピーだけをストリップすべきである。
読者のプログラムにバグがないという確信がない限り,実行形式を ストリップするのはおすすめしない.ただし,バグがある場合, ストリップしてない実行形式をどこかに取っておいて,実際に実行する ファイルはストリップしたものをインストールするというのは 構わないだろう.
プログラムを構築するうえで作成されたファイルを全部カレントディレクトリから 消す.コンフィギュレーションを記録したファイルは消さない. 構築の際に作成される可能性があるが,配布物に含まれているので通常は 作成しないファイルも保存する.
配布物に含まれていない `.dvi' ファイルは消す.
「ほぼ全部」というのは, `make maintainer-clean' を実行した場合,
ファイル `configure' だけは,
たとえ Makefile に書かれているルールから作り直すことが出来たとしても,
消してはならないからである.
もっと一般的にいうなら, `make maintainer-clean' は,
`confiugre' を実行して,プログラムの構築を解するのに必要な
ファイルは消してはいけないということである.
この例外を除いて, 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 プログラムを実行すべきである. 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 プログラムを実行させるべきである.
texi2dvi はTexinfo の配布物の一部である.(1) あるいは,
依存関係だけを書き, 後は GNU make にまかせる事もできる.
例えば, GCC バージョン1.40 配布用の tar ファイルは, `gcc-1.40'という名前 のサブディレクトリに中身を展開するようになっている.
このための最も簡単な方法は,適切な名前のサブディレクトリを作成し,
ln あるいは cpを使ってそのサブディレクトリにファイルを
インストールし,そのサブディレクトリを tar すればよい.
tar ファイルは gzip を使って圧縮すること.
例えば, GCC バージョン 1.40 の,実際に配布されるファイル名は
`gcc-1.40.tar.gz' となる.
dist ターゲット は,配布物が最新であることを保証するために,
配布物中のソース以外の全てのファイルに明示的に依存していなければならない.
GNUコーディング標準の「リリース」の章を参照.
以下のターゲットはそれがあれば便利なプログラムのために習慣的な名前として 提供します.
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)
|
あるいは、DESTDIR をサポートしたいのであれば以下のようにする。
# Make sure all installation directories (e.g. $(bindir))
# actually exist by making them if necessary.
installdirs: mkinstalldirs
$(srcdir)/mkinstalldirs \
$(DESTDIR)$(bindir) $(DESTDIR)$(datadir) \
$(DESTDIR)$(libdir) $(DESTDIR)$(infodir) \
$(DESTDIR)$(mandir)
|
このルールでは,コンパイルを行ったディレクトリを触ってはいけない. インストール先ディレクトリを作成すること以外はしてはならない.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
install ターゲットを書くときには、そこで使用するコマンドを
全て、三つのカテゴリに分類する必要があります。三つのカテゴリとは、ノーマルと
プレインストールとポストインストールです。
ノーマルのコマンドは、各ファイルを適切な場所に移動し、モードを 設定します。ノーマルコマンドは、パッケージに含まれているファイルを そのまま移動する場合以外は、どのファイルも変更していけません。
プレインストールとポストインストール用コマンドは、他のファイルを 変更する可能性があります。特に、システムワイドなコンフィギュレーシン ファイルやデータベースを変更し得ます。
プレインストールコマンドは、普通はノーマルのコマンドの前に実行され、 ポストインストールコマンドは、ノーマルコマンドの後に実行されます。
ポストインストールコマンドのもっとも一般的な使い方は、install-info
を実行することです。これは、ノーマルコマンドでは為し得ません。
何故なら、ファイル全体がインストールされたパッケージから単独で由来
しているのではないファイル(Info ディレクトリファイル)を変更するからです。
これは、そのパッケージの Info ファイルをインストールするノーマルコマンドの
後に実行する必要があるため、ポストインストールコマンドになっています。
プレインストールコマンドを必要とするプログラムはほとんどありませんが、 必要な場合に備えてこの機能を入れています。
install の規則のコマンドを三つのカテゴリに分けるには、
その間にカテゴリ行を挿入します。カテゴリ行は、次行以降のコマンドの
カテゴリを指定します。
各カテゴリ行は、タブと特別な Make 変数、それに付加的なコメントからなります。 三つの変数があり、各カテゴリに対し一つが対応します。変数名が カテゴリを指定します。カテゴリ行は、普通に 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.
|
プレアンインストールコマンドは、普通は Info ディレクトリファイルから エントリを削除するのに使います。
install と uninstall ターゲットに、インストール過程の
サブルーチンとして働くような依存物があるなら、それぞれの依存物に
対するコマンドの最初にカテゴリ行を置くべきです。そして、主となる
ターゲットのコマンドもやはりカテゴリ行で始める必要があります。
こうすることで、どの依存物が実際に実行されるかにはよらずに、各コマンドが
正しいカテゴリに置かれることが保証されます。
プレインストールとポストインストールコマンドは、以下のものを除いて どんなコマンドも実行すべきではありません。
[ 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 |
このようにコマンドを区別するのは,バイナリパッケージの作成を考慮した ためです.バイナリパッケージはインストールする必要のある実行形式 や他のファイルを全て持っており,独自のインストール方法も持っています. そのため,普通のインストールコマンドは実行する必要がないのです. しかし,バイナリパッケージはプレインストールコマンドとポストインストール コマンドを実行する必要があります.
バイナリパッケージを構築するためのプログラムは、プレインストールコマンドと ポストインストールコマンドを抜き出すことで動作します。 プレインストールコマンドを抜き出す一つの方法を示します。
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}
|
プレインストールコマンドの抽出の結果のファイルは、バイナリパッケージの インストールの一部として、シェルスクリプトとして実行されます。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
例えば Foo version 69.96 の配布物は,
`foo-69.96.tar.gz'という名の gzip された tar ファイルとしてパッケージに
してください.
これは `foo-69.96' という名のサブディレクトリに展開
されるようになっていなくてはなりません.
プログラムのインストールと構築時には,配布物中のどんなファイルも変更すべきでは ありません.プログラムの部分を構成しているファイルは,全てソースファイル と 非ソースファイルに分類されるべきだということです. ソースファイルは人間が書くもので,自動的には変更されません. 非ソースファイルは, Makefile の制御のもとに何らかのプログラムによって ソースファイルから生成されるものです.
配布には `README' というファイルを入れなくてはなりません. このファイルでは, パッケージの名前と, それが何をするものであるのかの 一般的な説明を行ないます. パッケージの中のサブディレクトリがあれば, 最上位のものついて, それぞれ目的が何かを説明するのも良いでしょう. `README' ファイルでは, パッケージのバージョン番号を述べたり, パッケージがどこに行けば見つかるかを記述しなくてはなりません.
`README' ファイルは, ファイル `INSTALL' について 言及しなければなりません. `INSTALL' には, インストール手順の 説明を書く必要があります.
また, `REAMDE' では, 複製条件を書いたファイルも参照して いなければなりません. GNU GPL を使うのであれば, `COPYING' という ファイルにそれを置くべきです. GNU LGPL を使うのであれば, `COPYING.LIB' というファイルに置くようにします.
通常,配布物の中に全てのソースファイルが入っていなければなりません.
非ソースファイルを入れてもかまいません.それらが最新でマシン独立な
らば,通常の構築の際に決して変更されないでしょう.
我々は, 通常 Bison, lex, TeX, makeinfo により
作成された非ソースファイルを含めています.
我々の配布物間の不要な依存関係を避ける助けになり,
ユーザはインストールしたいどのパッケージであってもインストールできるように
なります.
プログラムを構築, インストールする時に変更される非ソースファイルは 絶対に 配布物に含めてはいけません. 非ソースファイルを配布したかったら,新しい配布を作る時にそれが最新で あるかどうかをいつも確認してください.
配布物が展開されるディレクトリ（サブディレクトリも同様に）は,
誰でも書き込み可能（モード 777） になっていることを確認してください.
これは,tar アーカイブ中のファイルのオーナーとパーミッションを保存するような
古いバージョンの tar を使った場合,特権ユーザでなくても全てのファイルを
引き出せるようにするためです.
配布中のファイルは全て誰でも読めるようになってることを確かめてください.
配布物中には14文字より長い名前のファイルがないことを確認しましょう. 同様に, プログラムを構築したときにできるファイルにも１４文字より 長い名前のものがないことを確認してください. その理由は, POSIX 標準を間違って解釈しているシステムがあり, 昔のように名前を途中で切り落とす代わりに,長い名前のファイルを オープンすることを拒むからです.
配布物自体の中にシンボリックリンクを含んではなりません. tar ファイル中にシンボリックリンクがあると, シンボリックリンクをサポート していないシステムでは展開できないからです. また, 一つのファイルに対して異なったディレクトリで複数の名前を使うことは しないでください. あるファイルシステムでは, これを扱えず, 配布物を 展開できないからです.
ファイル名が全て MS-DOS上で一意的になることを確かめましょう. MS-DOSでのファイル名は,最初の８文字と,オプションで付くピリオドとそれに続く ３文字以内の文字から成ります. MS-DOS はピリオドの前後両方で,余分な文字を 切り捨てます.したがって`foobarhacker.c' と `foobarhacker.o' は `foobarha.c'と `foobarha.o'に縮められるので区別されます.
`*.texinfo' または `*.texi' ファイルを印刷するのに 使う`texinfo.tex'のコピーは必ず配布物中にいれましょう.
もし, regex, getpot, obstack, termcap などの小さな GNU ソフトウェア パッケージが必要なら, 一緒に配布物に入れましょう. 一緒に入れとかないと,配布ファイルは少し小さくなりますが, 他にどんなファイルを手に入れたらいいのか知らないユーザにとっては不便です.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |