[ < ] [ > ]   [ << ] [上] [ >> ]         [冒頭] [目次] [見出し] [ ? ]

14. Makefileの約束ごと

この では、GNUのプログラムに関するMakefileの記述に関しての約束事を 記します。Automakeを利用することによって、それらの約束事にそったMakefileの 記述の手助けをしてくれます。

14.1 Makefileに関する一般的な約束事   General Conventions for Makefiles
14.2 Makefileにおけるユーティリティ   Utilities in Makefiles
14.3 コマンド指定の変数   Variables for Specifying Commands
14.4 インストールディレクトリの変数   Variables for Installation Directories
14.5 ユーザーにとっての標準ターゲット   Standard Targets for Users
14.6 インストールコマンドのカテゴリー   Three categories of commands in the ‘install’ rule: normal, pre-install and post-install.
[ < ] [ > ]   [ << ] [上] [ >> ]         [冒頭] [目次] [見出し] [ ? ]

14.1 Makefileに関する一般的な約束事

すべてのMakefileは、以下の行を含まなければなりません。

 
SHELL = /bin/sh

これは、SHELL変数が環境変数から継承される場合のシステムでの トラブルを回避するためです。（しかし、GNUのmakeでは これは問題にはなりません。）

異なるmakeプログラムは、互換性のないサフィックスのリストと 暗黙のルールを持ち、これが混乱や誤ったふるまいを引き起こします。 したがって、以下のように特定のMakefileにおいて、必要なサフィックス だけを明示的に使用するほうがよいのです。

 
.SUFFIXES:
.SUFFIXES: .c .o

最初の行でサフィックスのリストをクリアし、次の行で、このMakefileでの 暗黙のルールに必要なサフィックスを導入しています。

コマンド実行のためのパスに、‘.’も入ると仮定しないでください。 makeの際のパッケージの一部としてプログラムを実行する際は、その プログラムがmakeの一部としてビルドされる場合には‘./’を、 ソースコードの変化のないファイルの場合には‘$(srcdir)/’を使用します。 これらのサフィックスのどれもない場合には、カレントのサーチパスが使用されます。

‘./’（ビルドディレクトリ）と‘$(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

以下のように書き換えられ、

 
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でターゲットのビルドと インストールを行なうことを試してみてください。

[ < ] [ > ]   [ << ] [上] [ >> ]         [冒頭] [目次] [見出し] [ ? ]

14.2 Makefileにおけるユーティリティ

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

圧縮プログラムのzipは、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やスクリプトでそれらを使用することは かまいません。

[ < ] [ > ]   [ << ] [上] [ >> ]         [冒頭] [目次] [見出し] [ ? ]

14.3 コマンド指定の変数

Makefileは、あるコマンド、オプションなどをオーバーライドする変数を 提供する必要があります。

また、とくに、多くのユーティリティプログラムは変数を経由して実行 すべきです。したがって、たとえばBisonを使用する場合には、デフォルトの 設定が‘BISON = bison’になっているBISONと名付けられた変数 を使用し、$(BISON)で引用するようにします。

一方、ln、rm、mvなどのファイル管理ユーティリティは、 ユーザーがほかのプログラムで置き換える必要がないため、同じように変数経由で 引用する必要はありません。

個々のプログラム名変数は、プログラムにオプションを与えるための オプション変数とともに用いられます。オプション変数を与えるために、 たとえば、BISONFLAGSのようにプログラム名変数に‘FLAGS’を 追加してください。（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) $<

CFLAGSに‘-g’を含むようにしてください。なぜならば、適切な コンパイルに対して必要ではないためです。ただし、それは推奨される デフォルトとみなすことができます。 デフォルトで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

場合によっては、DESTDIRの値をターゲットファイル名にしても かまいません。そうすることで、インストーラがあとで実際のファイルシステムの ターゲットにコピーができるようにスナップショットを作成することになります。 MakefileでDESTDIRの値をセットしてはなりません。また、 インストールされたファイルにその値を含めてはいけません。 DESTDIRのサポートによって、前記の例は以下のようになります。

 
$(INSTALL_PROGRAM) foo $(DESTDIR)$(bindir)/foo
$(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a

インストールのコマンドの2番目の引数にはつねにファイル名を用い、 ディレクトリ名は用いません。インストールされる個々のファイルに対しては コマンドを区切って使用します。

[ < ] [ > ]   [ << ] [上] [ >> ]         [冒頭] [目次] [見出し] [ ? ]

14.4 インストールディレクトリの変数

インストールディレクトリは、つねに変数で名前をつけられなければなりません。 そうすることによって、標準的でない場所へのインストールも簡単になるのです。 それらの変数の標準的な名前は、以下で記述しています。また、それらは標準的な ファイルシステムのレイアウトに基づいていて、SVR4、4.4BSD、Linux、 Ultrix v4などの最近のオペレーティングシステムでは若干の相違があります。

それら2つの変数は、インストールのためにrootにセットされます。ほかの インストールディレクトリのすべては、その2つのうちの1つのサブディレクトリに セットされ、それら2つのディレクトリに直接インストールされるべきでは ありません。

‘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’を実行する場合は、そのプログラムは再コンパイルされません。

実行可能なプログラムは、以下のディレクトリの1つにインストールされます。

‘bindir’

ユーザーが実行可能な実行プログラムをインストールするディレクトリ。 これは通常は、‘/usr/local/bin’ですが、‘$(exec_prefix)/bin’の ように記述します。（Autoconfを使用する場合は、‘@bindir@’のように 記述します。）

‘sbindir’

シェルから実行可能なプログラムのインストールのためのディレクトリ。 ただし、一般的にはシステム管理者にのみ有益なディレクトリです。通常は ‘/usr/local/sbin’ですが、‘$(exec_prefix)/sbin’と記述されます。 （Autoconfを使用する場合は、‘@sbindir@’のように記述します。）

‘libexecdir’

ユーザーよりも、むしろほかのプログラムから実行可能なプログラムの インストールのためのディレクトリ。通常は‘/usr/local/libexec’ですが、 ‘$(exec_prefix)/libexec’と記述されます。（Autoconfを使用する場合は、 ‘@libexecdir@’のように記述します。）

プログラムの実行時に使用されるデータファイルは、2つのカテゴリーに分けられます。

このことは6種類の異なる可能性につながります。しかし、 オブジェクトファイルとライブラリが別として、アーキテクチャ依存の ファイルの使用は避けたいと考えます。ほかのデータファイルをアーキテクチャ 独立にすることは、よりクリアにすることで、一般的には難しくはありません。

したがって、Makefilesがディレクトリを指定するのに使用すべき変数をあげます。

‘datadir’

リードオンリーアーキテクチャから独立したデータファイルのインストールの ためのディレクトリ。通常は‘/usr/local/share’ですが、 ‘$(prefix)/share’と記述されます。（Autoconfを使用する場合は、 ‘@datadir@’のように記述します。）特別な例外として、以下の ‘$(infodir)’と‘$(includedir)’を確認してください。

‘sysconfdir’

単独のマシンと結び付いたファイル、すなわちホストの設定ファイルのような リードオンリーファイルをインスト−ルするディレクトリ。メイラや ネットワーク設定ファイルや‘/etc/passwd’などがこれに属します。 これらのすべてのファイルはASCIIテキストファイルです。通常は ‘/usr/local/etc’ですが、‘$(prefix)/etc’と記述されます。 （Autoconfを使用する場合は、‘@sysconfdir@’のように記述します。）

このディレクトリに実行可能なファイルをインスト−ルしてはなりません （それらは‘$(libexecdir)’、あるいは‘$(sbindir)’に属している はずです）。また、それらが使用されているあいだにファイルを インストールしてはなりません（システムのコンフィギュレーションを変更する 目的を持つプログラムは実行を停止させます）。 それらは‘$(localstatedir)’に属しています。

‘sharedstatedir’

プログラムが実行中に変更を加えるアーキテクチャ独立のデータファイルを インストールするディレクトリ。通常は‘/usr/local/com’ですが、 ‘$(prefix)/com’と記述されます。（Autoconfを使用する場合は、 ‘@sharedatadir@’のように記述します。）

‘localstatedir’

特定のマシンと結び付いた、プログラムの実行中に変更の加えられる データファイルをインストールするディレクトリ。パッケージの操作の際には、 ユーザーはこのディレクトリのファイルを変更する必要はありません。 分割されたそのような設定ファイルは‘$(datadir)’、あるいは ‘$(sysconfdir)’におきます。‘$(localstatedir)’は通常 ‘/usr/local/var’ですが、‘$(prefix)/var’と記述されます。

‘libdir’

オブジェクトファイルとオブジェクトコードのライブラリのためのディレクトリ。 ここに実行可能ファイルをインストールしてはなりません。そのかわりに ‘$(libexecdir)’にそれらを置いてください。libdirの値は 通常は‘/usr/local/lib’ですが、‘$(exec_prefix)/lib’と 記述されます。（Autoconfを使用する場合は、‘@libdir@’のように 記述します。）

‘infodir’

パッケージのInfoファイルのインストールのためのディレクトリ。 デフォルトでは、‘/usr/local/info’ですが、‘$(prefix)/info’と 記述されます。（Autoconfを使用する場合は、‘@infodir@’のように 記述します。）

‘lispdir’

パッケージに含まれるEmacs Lispファイルのインストールのためのディレクトリ。 デフォルトでは、‘/usr/local/share/emacs/site-lisp’ですが、 ‘$(prefix)/share/emacs/site-lisp’と記述されます。

Autoconfを使用する場合は、デフォルトで‘@lispdir@’のように 記述します。‘@lispdir@’が動作できるように、以下のような行を ‘configure.in’ファイルに記述する必要があります。

 
lispdir='${datadir}/emacs/site-lisp'
AC_SUBST(lispdir)
‘includedir’

C言語の‘#include’ディレクティブによってユーザープログラムで インクルードされるヘッダファイルのためのディレクトリ。通常は ‘/usr/local/include’ですが、‘$(prefix)/include’と 記述されます。（Autoconfを使用する場合は、‘@includedir@’のように 記述します。）

GCCを除く大部分のコンパイラは、‘/usr/local/include’のディレクトリの ヘッダファイルを探しません。したがって、この方法でヘッダファイルを インストールするのはGCCの場合にのみ有益です。ライブラリによっては、 GCCでしか動作しないものもあるため、このことは問題にならない場合が あります。しかし、ライブラリによってはほかのコンパイラでも動作するように なっています。その場合には、ヘッダファイルは、includedirと oldincludedirで指定された2つのディレクトリにインストール されなければなりません。

‘oldincludedir’

GCC以外のコンパイラで使用される‘#include’ヘッダファイルの インストールディレクトリ。通常は‘/usr/include’です。（Autoconfを 使用する場合は、‘@oldincludedir@’のように記述します。）

Makefileコマンドはoldincludedirの値が空かどうかを チェックしなければなりません。空である場合には、 それを使用しようとしません。また、ヘッダファイルの2番目の インストールをキャンセルすることになります。

パッケージは、同じパッケージによるものでない限り、このディレクトリに 存在するヘッダファイルを置き換えるべきではありません。したがって、 Fooというパッケージがヘッダファイル‘foo.h’を提供している場合、 （1）‘foo.h’がない場合、あるいは（2）パッケージFooによる ‘foo.h’が存在する場合のどちらの場合でもoldincludedir ディレクトリにインストールしなければなりません。

‘foo.h’がパッケージFooのものであるかどうかを伝えるために、 魔法の文字列をファイルにコメントの一部として入れてください。 そして、その文字列をgrepにかけます。

Unixスタイルのmanページが、以下の1つのデイレクトリにインストールされます。

‘mandir’

パッケージのmanページのインスト−ルのためのトップレベルのディレクトリ。 通常は、‘/usr/local/man’ですが、‘$(prefix)/man’と 記述すべきです。（Autoconfを使用する場合は、‘@mandir@’のように 記述します。）

‘man1dir’

セクション1のmanページのインスト−ルディレクトリで、 ‘$(mandir)/man1’と記述します。

‘man2dir’

セクション2のmanページのインスト−ルディレクトリで、 ‘$(mandir)/man2’と記述します。

‘…’

GNUソフトウェアに関する主要なドキュメントをmanページで作らないでください。 そのかわりにTexinfoで記述してください。Manページは、Unix上で二次的な アプリケーションのみを動作させる人たちのためだけにあるのです。

‘manext’

インストールされたmanページに対するファイル名の拡張。これは‘.’に 続いて適切な数字がつけられます。

‘man1ext’

インストールされたセクション1のmanページに対するファイル名の拡張。

‘man2ext’

インストールされたセクション2のmanページに対するファイル名の拡張。

‘…’

マニュアルの1セクションよりも多くmanページをインストールする必要がある場合には、‘manext’のかわりにこれらを使用してください。

最終的に、以下の変数をセットする必要があります。

‘srcdir’

コンパイルされるソースに対するディレクトリ。この変数の値は通常は 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

標準的なユーザー指定のディレクトリの1つに非常に多くのファイルを インストールする場合、そのプログラムに固有のサブディレクトリにそれらを グループ化することが便利です。そうすることによって、必要なサブディレクトリを 作成するためのinstallルールを記述するのがよいでしょう。

上記にリストされた変数の値に、サブディレクトリを含むようにすることを ユーザーに期待はできません。インストールディレクトリに関して均一な 変数名のセットを持つというアイデアは、いくつかの異なるGNUパッケージに 対してまったく同じ値をユーザーが指定できるようになります。このことが 有益であるように、すべてのパッケージはユーザーがそうした場合に うまく動作するようにデザインされていなければなりません。

[ < ] [ > ]   [ << ] [上] [ >> ]         [冒頭] [目次] [見出し] [ ? ]

14.5 ユーザーにとっての標準ターゲット

すべてのGNUプログラムは、Makefileに以下のターゲットを持たなければなりません。

‘all’

プログラム全体のコンパイル。これがデフォルトのターゲットです。 このターゲットはいかなるドキュメントファイルも再構成する必要はありません。 ディストリビューションには通常はInfoファイルが含まれていなければならず、 要求があった場合にDVIファイルが作られるようになっていなければなりません。

デフォルトでは、Makeのルールは‘-g’でコンパイルとリンクを行ない、 その結果、実行プログラムはデバッグシンボルを持ちます。ヘルプ機能の ないことを気にしないユーザーの場合はあとで実行可能プログラムを 分離することができます。

‘install’

コンパイルと実行プログラムとライブラリの実際に使用する際のファイル名への コピー。プログラムが適切にインストールされるかを確認する簡単なテストが ある場合は、このターゲットはそれを実行します。

インスト−ルの最中に実行プログラムを分離してはなりません。向こう見ずな ユーザーは、install-stripターゲットでこれを実行する場合があります。

可能な場合には、プログラムがビルドされるディレクトリ、すなわち ‘make all’が実行されるディレクトリにおいて何も変更されないように installターゲットルールを記述してください。

あらかじめ存在しない場合には、コマンドはファイルがインスト−ルされるのに 必要なすべてのディレクトリを作成するでしょう。これには、変数prefixと exec_prefixの値として指定されたディレクトリが含まれ、同じように、 必要なサブディレクトリも含まれます。これを行なうには以下に書かれたように、 installdirsターゲットによります。

manページのインストールのコマンドのまえに‘-’を使用します。 そうすることによって、makeはあらゆるエラーを無視します。これは、 Unixのmanページドキュメントシステムがインストールされていないシステムの 場合です。

Infoファイルをインストールするには、$(INSTALL_DATA) （see section コマンド指定の変数.）による‘$(infodir)’に それらをコピーします。その後、プログラムが存在する場合には install-infoを実行します。install-infoは1つのプログラムで、 Infoの‘dir’ファイルを編集し、与えられたInfoファイルのメニューエントリを 追加あるいはアップデートします。また、これはTexinfoパッケージの一部で、 以下にインストールの例を示します。

 
$(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ターゲットを記述する際は、コマンドを3つのカテゴリに分ける 必要があります。それらのコマンドは、通常のもの、インストール前のもの、 インストール後のものです。 See section インストールコマンドのカテゴリー.。

‘uninstall’

インストールしたファイル、すなわち‘install’ターゲットが作成した すべてのファイルを削除する。

このルールは、コンパイルが行なわれるディレクトリを変更せず、ファイルが インストールされるディレクトリだけを変更します。

アンインストールのコマンドは、ちょうどインストールコマンドと同様に3つの カテゴリーに分けられます。 See section インストールコマンドのカテゴリー.。

‘install-strip’

installに似ていますが、インストール中に実行プログラムを分離します。 多くのケースでは、このターゲットの定義は非常に簡単なものになります。

 
install-strip:
        $(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \
                install

通常は、プログラムがバグを持っていないことが確信できる場合を除いて、 実行ファイルを分離することは推奨されません。しかしながら、バグがある場合を 考慮して、分離していない実行プログラムをどこかに保存しながら、 分離した実行ファイルをインストールするのは妥当なことです。

‘clean’

プログラムのビルドの際に作成されたカレントディレクトリのすべての ファイルの削除をします。ただし、コンフィギュレーションを記録している ファイルを削除してはなりません。また、ビルドによって作成される ファイルは保存しますが、通常それらはディストリビューションと一緒に なっているものではありません。

ディストリビューションの一部でない場合は‘.dvi’ファイルを削除します。

‘distclean’

プログラムのビルドあるいは設定によって、作成されたカレントディレクトリの すべてのファイルの削除をします。ソースを展開してほかのファイルを作成せずに プログラムのビルドを行なった場合は、‘make distclean’は、 ディストリビューションにあるファイルだけを残すでしょう。

‘mostlyclean’

‘clean’に似ていますが、再コンパイルするのを避けたいいくつかの ファイルを削除することを回避します。たとえば、GCCに対する‘mostlyclean’ ターゲットは‘libgcc.a’を削除しません。なぜなら、再コンパイルの必要性は めったになく、時間も長くかかるからです。

‘maintainer-clean’

Makefileによって再構築可能なカレントディレクトリのほとんどすべての ファイルの削除をします。一般的には、distcleanで削除される すべてのファイルを含みますが、これに加えて、Bisonによって作成された Cソースファイル、タグテーブル、Infoファイルなどです。

ほとんどすべてという意味は、‘make maintainer-clean’の実行は、 Makefileのなかでルールを用いて‘configure’が再作成可能な場合でさえ、 ‘configure’を削除すべきではないからです。さらに一般的には、 ‘make maintainer-clean’は、‘configure’の実行とプログラムの ビルドの開始の順序に従って、存在しなくてはならないすべてのものを 削除してはならないのです。ただし、maintainer-cleanは再構成可能な ほかのものをすべて削除しなければならず、これは唯一の例外といえます。

‘maintainer-clean’ターゲットは、パッケージの管理者によって 使用されることを意図しています。‘make maintainer-clean’によって、 削除されたファイルのいくつかのファイルの再構築には特別なツールが 必要になるかもしれません。通常はそれらのファイルがディストリビューションに 含まれているので、再構築を容易にする点については注意を払いません。 再度ディストリビューションを展開する必要がある場合には容赦してほしいものです。

ユーザーがこのことに気づくように、特別なmaintainer-cleanターゲットに 対するコマンドは以下の2つの事柄で始まらなければなりません。

 
@echo 'This command is intended for maintainers to use; it'
@echo 'deletes files that may need special tools to rebuild.'
‘TAGS’

このプログラムに対するタグテーブルのアップデート。

‘info’

必要なInfoファイルの生成。ルールの記述の仕方で、もっともよいのは以下の とおりです。

 
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’

すべてのTexInfoドキュメントに対してDVIファイルを生成します。 例としては、

 
dvi: foo.dvi

foo.dvi: foo.texi chap1.texi chap2.texi
        $(TEXI2DVI) $(srcdir)/foo.texi

Makefileにおいて変数TEXI2DVIを定義する必要があります。それが プログラムtexi2dviを実行させることになります。そのプログラムは Texinfoディストリビューションに含まれ、(2)かわりに、依存関係だけを記述して、GNU makeに コマンドを提供させるようにすべきでしょう。

‘dist’

このプログラムに関するディストリビューション用のtarファイルの生成をします。 ディストリビューション用のパッケージの名前であるサブディレクトリ名を持つ tarファイルのなかのファイル名を用いてtarファイルはセットされなければ なりません。この名前にはバージョン番号も含みます。

たとえば、GCCバージョン1.40のディストリビューション用のtarファイルは、 ‘gcc-1.40’という名前のサブディレクトリに展開されます。

適切なサブディレクトリの名前を生成するためのもっとも簡単な方法は、 適切なファイルをインストールするためにlnあるいはcpを用いて、 そのサブディレクトリでtarを実行することです。

gzipを使用してtarファイルを圧縮します。たとえば、GCCバージョン1.40の 実際のディストリビューションは‘gcc-1.40.tar.gz’となっています。

distターゲットは、ディストリビューションに含まれるソースでない ファイルに依存しているはずで、最新のものかどうかを確認してください。 See (standards)Releases section ‘Making Releases’ in GNU Coding Standards.。

‘check’

セルフテストを実行します。テストを行なうまえにプログラムのビルドを行う 必要がありますが、プログラムのインストロールを行う必要はありません。 セルフテストはプログラムがビルドされて、しかしながらインストールは されないように記述すべきです。

以下のターゲットは有益なプログラムとして、従来の名前で存在しています。

installcheck

インストールのテストを実行します。テストを実行するまえにビルドと インストールが必要です。この際、サーチパスのなかに‘$(bindir)’が あると仮定してはいけません。

installdirs

‘installdirs’と名付けられたターゲットを、ファイルがインストールされる ディレクトリと親ディレクトリを作成するために加えることは有益です。この場合、 ‘mkinstalldirs’と呼ばれるスクリプトが便利です。このスクリプトは Texinfoパッケージに含まれていますし、‘/gd/gnu/lib/mkinstalldirs’に あります。以下のようなルールを使用することができます。

 
# Make sure all installation directories (e.g. $(bindir))
# actually exist by making them if necessary.
installdirs: mkinstalldirs
        $(srcdir)/mkinstalldirs $(bindir) $(datadir) \
                                $(libdir) $(infodir) \
                                $(mandir)

このルールは、コンパイルが行われるディレクトリの修正をしてはならず、 インストールディレクトリの作成だけを行なうべきです。

[ < ] [ > ]   [ << ] [上] [ >> ]         [冒頭] [目次] [見出し] [ ? ]

14.6 インストールコマンドのカテゴリー

installターゲットを記述する際は、コマンドを3つに分類する必要が あります。通常のコマンド、pre-installationコマンド、そして post-installationコマンドです。

通常のコマンドは適切な場所にファイルを移動し、モードを設定します。 パッケージに含まれるコマンドを除いて、それらはいかなるファイルも 変更することはできません。

インストール前とインストール後のコマンドは他のファイルを変更することが できます。とくに、グローバルな設定ファイルやデータベースを編集することが 可能です。

インストール前のコマンドは一般に、通常のコマンドよりもまえに実行されます。 また、インストール後のコマンドは反対に通常のコマンドよりもあとに実行されます。

インストール後のコマンドでもっとも一般的なのはinstall-infoの実行です。 このコマンドは通常のコマンドでは実行されません。なぜなら、インストール されたパッケージによるものでないファイル（Infoディレクトリ）を変更して しまうからです。パッケージのInfoファイルをインストールする通常の コマンドのあとに実行される必要があるため、このコマンドはインストール後の コマンドなのです。

多くのプログラムではインストール前のコマンドは必要としません、しかし、 必要な場合の特徴をあげます。

installルールにおいてコマンドを3つのカテゴリーに分類するには、 category linesをそれらのあいだに挿入します。カテゴリー行は、 それ以下のコマンドのカテゴリーを特定します。

カテゴリー行は、タブと特別なMake変数への引用、そして場合によっては最後の コメントからなっています。変数は3種類使用することができ、それぞれの カテゴリーに対して1つあり、その名前がカテゴリーを特定します。通常の 実行においてはカテゴリー行はオプションなしです。なぜならこれらの 3つのMake変数は通常は未定義であるからです（Makefileのなかで 定義してはいけません）。

3つのカテゴリー行を示します。それぞれ、何を表わすかのコメントもついています。

 
        $(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

コマンドをこのように区別することの理由は、バイナリのパッケージを 作ることによります。一般的にバイナリのパッケージはインストールされるべき 実行ファイルとそのほかのファイルを含みます。そしてインストールのための 独自の方法を持ちます。そうすることによって通常のインストールコマンドを 実行する必要がなくなるのです。しかしながら、バイナリパッケージの インストールはインストール前とインスト−ル後のコマンドを実行する必要が あります。

バイナリパッケージをビルドするプログラムはインストール前と インストール後のコマンドの展開によって動作します。ここにインストール前の コマンドの展開の1つの方法を示します。

 
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}

インストール前のコマンドの結果生じているファイルはバイナリパッケージの インストールの一部としてシェルスクリプトのように実行されます。

[ << ] [ >> ]           [冒頭] [目次] [見出し] [ ? ]

この文書は新堂 安孝によって2009年9月22日にtexi2html 1.82を用いて生成されました。