この章では、GNU プログラム向けの Makefile を書くときの慣習について説明します。Automake を使うと、これらの慣習に沿った Makefile を書く手助けになります。移植性の高い Makefile についてさらに詳しく知りたい方は、POSIX の規格と、Autoconf マニュアルの Portable Make Programming の項を参照してください。
DESTDIR: 段階的インストールへの対応すべての Makefile には、次の1行を入れておくべきです:
SHELL = /bin/sh
これは、SHELL 変数が環境から引き継がれてしまうおそれのあるシステムで、トラブルを避けるためです。(GNU make ではこの問題は一切起こりません。)
make プログラムによっては、サフィックスのリストや暗黙のルールが互いに非互換になっており、これが混乱や誤動作の原因になることがあります。そこで、その Makefile で必要なサフィックスだけを使って、サフィックスのリストを明示的に設定しておくのがよいでしょう。次のようにします:
.SUFFIXES: .SUFFIXES: .c .o
最初の行でサフィックスのリストをいったん空にし、2行目で、この Makefile 内で暗黙のルールの対象となりうるサフィックスをすべて導入しています。
コマンドを実行するときのパスに .(カレントディレクトリ)が含まれていると思い込まないでください。make の最中に、自分のパッケージの一部であるプログラムを実行する必要がある場合は、そのプログラムが make の一部としてビルドされるものなら ./ を、ソースコードの一部で変化しないファイルなら $(srcdir)/ を必ず付けるようにしてください。これらの接頭辞のどちらも付けないと、その時点での探索パスが使われてしまいます。
./(ビルドディレクトリ)と $(srcdir)/(ソースディレクトリ)を区別することは重要です。なぜなら、ユーザーは configure の「--srcdir」オプションを使って、別のディレクトリでビルドできるからです。次のような形のルールは、
foo.1 : foo.man sedscript
sed -f sedscript foo.man > foo.1
ビルドディレクトリがソースディレクトリと異なるときに失敗します。なぜなら、foo.man と sedscript はソースディレクトリの中にあるからです。
GNU make を使う場合、前提条件のファイルが1つだけのときは、ソースファイルを見つけるのに「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 -f $(srcdir)/sedscript $(srcdir)/foo.man > $@
GNU の配布物には、ソースファイルではないファイルもいくつか含まれているのが普通です。たとえば Info ファイルや、Autoconf・Automake・Bison・Flex の出力などです。これらのファイルは通常ソースディレクトリに置かれているため、ビルドディレクトリではなく、常にソースディレクトリに置かれるべきです。したがって、それらを更新する Makefile のルールは、更新後のファイルをソースディレクトリに置くようにすべきです。
ただし、配布物に含まれないファイルについては、Makefile はそれをソースディレクトリに置くべきではありません。通常の状況でプログラムをビルドしても、ソースディレクトリを何ら変更すべきではないからです。
少なくともビルド用とインストール用のターゲット(およびそのすべてのサブターゲット)は、並列 make でも正しく動くように作るよう心がけてください。
Makefile のコマンド(および configure のようなシェルスクリプト)は、csh ではなく sh(伝統的な Bourne シェルと POSIX シェルの両方)で動くように書いてください。ksh や bash の特別な機能や、伝統的な Bourne sh では広くサポートされていない POSIX の機能は使わないでください。
configure スクリプトと、ビルドおよびインストール用の Makefile のルールでは、次のユーティリティ以外は直接使うべきではありません:
awk cat cmp cp diff echo expr false grep install-info ln ls mkdir mv printf pwd rm rmdir sed sleep sort tar test touch tr true
gzip のような圧縮プログラムは、dist ルールで使ってかまいません。
基本的に、これらのプログラムの中でも、広くサポートされている(たいていは POSIX で規定されている)オプションや機能だけを使うようにしてください。たとえば「mkdir -p」は便利ではありますが、使わないでください。これをまったくサポートしていないシステムが少数あり、他のシステムでも並列実行の際に安全ではないからです。既知の非互換性の一覧については、Autoconf マニュアルの Portable Shell Programming の項を参照してください。
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_PROGRAM のデフォルトは $(INSTALL)、INSTALL_DATA のデフォルトは ${INSTALL} -m 644 にすべきです。)そして、実際にインストールを行うコマンドとして、実行可能ファイルにはこれらの変数のうち前者を、実行可能でないファイルには後者を使うべきです。これらの変数の最小限の使い方は次のとおりです:
$(INSTALL_PROGRAM) foo $(bindir)/foo $(INSTALL_DATA) libfoo.a $(libdir)/libfoo.a
ただし、次の節で説明するように、ターゲットファイルに DESTDIR という接頭辞を付けられるようにしておくほうが望ましいです。
次のように、最後の引数をディレクトリにして、複数のファイルを1つのコマンドでインストールすることも許容されます(ただし必須ではありません):
$(INSTALL_PROGRAM) foo bar baz $(bindir)
DESTDIR: 段階的インストールへの対応
DESTDIR は、インストールされる各ターゲットファイルの先頭に付け加える変数です。次のように使います:
$(INSTALL_PROGRAM) foo $(DESTDIR)$(bindir)/foo $(INSTALL_DATA) libfoo.a $(DESTDIR)$(libdir)/libfoo.a
DESTDIR 変数は、ユーザーが make のコマンドラインで絶対ファイル名として指定します。たとえば次のようにします:
make DESTDIR=/tmp/stage install
DESTDIR をサポートすべきなのは install* と uninstall* のターゲットだけです。これらが、DESTDIR が役に立つ唯一のターゲットだからです。
もしインストール処理が通常 /usr/local/bin/foo と /usr/local/lib/libfoo.a をインストールするものだとすると、上の例のように起動されたインストールでは、代わりに /tmp/stage/usr/local/bin/foo と /tmp/stage/usr/local/lib/libfoo.a がインストールされます。
このように各ターゲットの先頭に DESTDIR 変数を付け加えることで、段階的インストール(staged install)が可能になります。これは、インストールされるファイルを本来あるべき場所に直接置くのではなく、いったん一時的な場所(DESTDIR)にコピーする方法です。それでも、インストールされるファイルの相対的なディレクトリ構造は保たれ、ファイル内に埋め込まれたファイル名が書き換えられることもありません。
DESTDIR の値は、Makefile の中ではいっさい設定すべきではありません。そうすれば、デフォルトではファイルが本来あるべき場所にインストールされます。また、DESTDIR を指定してもソフトウェアの動作がいっさい変わらないようにすべきです。したがって、その値をどのファイルの内容にも含めてはいけません。
DESTDIR のサポートは、パッケージの作成でよく使われます。また、特定のパッケージがどこに何をインストールするのかを理解したいユーザーや、本来は保護された領域へのインストール権限を持たないユーザーが、その権限を得る前にビルドとインストールを済ませておきたい場合にも役立ちます。さらに、stow のようなツールでも便利です。これは、コードをある場所にインストールしつつ、シンボリックリンクや特別なマウント操作によって別の場所にインストールされたように見せかけるツールです。こうした理由から、絶対的な必須要件ではないものの、GNU パッケージは DESTDIR をサポートすることを強く推奨します。
インストール先のディレクトリは、標準的でない場所にも簡単にインストールできるよう、常に変数で名前を付けておくべきです。これらの変数の標準的な名前と、GNU パッケージで設定すべき値を、以下で説明します。これらは標準的なファイルシステムのレイアウトに基づいており、その派生形が GNU/Linux やその他の現代的なオペレーティングシステムで使われています。
インストールする人は、make を呼ぶとき(たとえば make prefix=/usr install)や configure を呼ぶとき(たとえば configure --prefix=/usr)に、これらの値を上書きできることが前提になっています。GNU パッケージは、インストール先のシステムでこれらの変数にどの値がふさわしいかを推測しようとすべきではありません。ここで指定するデフォルト設定を使ってください。そうすれば、すべての GNU パッケージが同じように振る舞うので、インストールする人は望みどおりのレイアウトを実現できます。
インストール先のディレクトリと、その親ディレクトリは、そこにインストールする前に(必要であれば)すべて作成しておくべきです。
最初の2つの変数は、インストールのルート(基点)を設定します。他のすべてのインストール先ディレクトリは、この2つのどちらかのサブディレクトリにすべきで、この2つのディレクトリには何も直接インストールすべきではありません。
prefix以下に挙げる変数のデフォルト値を組み立てるために使われる接頭辞です。prefix のデフォルト値は /usr/local にすべきです。完全な GNU システムをビルドするときは、prefix は空になり、/usr は / へのシンボリックリンクになります。(Autoconf を使う場合は「@prefix@」と書きます。)
プログラムをビルドしたときとは異なる prefix の値で「make install」を実行しても、プログラムが再コンパイルされないようにすべきです。
exec_prefix以下に挙げる変数のうちいくつかのデフォルト値を組み立てるために使われる接頭辞です。exec_prefix のデフォルト値は $(prefix) にすべきです。(Autoconf を使う場合は「@exec_prefix@」と書きます。)
一般に、$(exec_prefix) はマシン固有のファイル(実行可能ファイルやサブルーチンライブラリなど)を格納するディレクトリに使い、$(prefix) はそれ以外のディレクトリに直接使います。
プログラムをビルドしたときとは異なる exec_prefix の値で「make install」を実行しても、プログラムが再コンパイルされないようにすべきです。
実行可能なプログラムは、次のディレクトリのいずれかにインストールします。
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@」と書きます。)
「libexecdir」の定義はすべてのパッケージで共通なので、自分のパッケージのデータはそのサブディレクトリにインストールすべきです。たいていのパッケージは、データを $(libexecdir)/package-name/ の下に、場合によってはさらにそのサブディレクトリ(たとえば $(libexecdir)/package-name/machine/version)の中にインストールします。
プログラムが実行中に使うデータファイルは、2つの観点で分類されます。
これで6通りの可能性が生まれます。しかし、オブジェクトファイルとライブラリを除いて、アーキテクチャ依存のファイルを使うことは推奨したくありません。それ以外のデータファイルはアーキテクチャ非依存にするほうがずっとすっきりしますし、たいていそれほど難しくもありません。
これらさまざまな種類のファイルを置く場所を指定するために Makefile が使うべき変数は、次のとおりです:
読み取り専用でアーキテクチャ非依存のデータファイルを収めるディレクトリツリーのルートです。通常は /usr/local/share ですが、$(prefix)/share と書きます。(Autoconf を使う場合は「@datarootdir@」と書きます。)「datadir」のデフォルト値はこの変数を基にしています。「infodir」「mandir」などもそうです。
このプログラム固有の、読み取り専用でアーキテクチャ非依存のデータファイルをインストールするディレクトリです。通常は「datarootdir」と同じ場所ですが、変数を2つに分けてあります。これにより、Info ファイルや man ページなどの場所を変えずに、このプログラム固有のファイルだけを移動できます。
通常は /usr/local/share ですが、$(datarootdir) と書きます。(Autoconf を使う場合は「@datadir@」と書きます。)
「datadir」の定義はすべてのパッケージで共通なので、自分のデータはそのサブディレクトリにインストールすべきです。たいていのパッケージは、データを $(datadir)/package-name/ の下にインストールします。
単一のマシンに関わる読み取り専用のデータファイル、すなわちホストを設定するためのファイルをインストールするディレクトリです。メーラーやネットワークの設定ファイル、/etc/passwd などがここに属します。このディレクトリ内のファイルはすべて、ふつうの ASCII テキストファイルであるべきです。通常は /usr/local/etc ですが、$(prefix)/etc と書きます。(Autoconf を使う場合は「@sysconfdir@」と書きます。)
このディレクトリに実行可能ファイルをインストールしてはいけません(それらはおそらく $(libexecdir) か $(sbindir) に属します)。また、通常の使用の過程で変更されるファイルもインストールしないでください(システムの設定を変更することを目的とするプログラムは除きます)。そうしたファイルはおそらく $(localstatedir) に属します。
アーキテクチャ非依存のデータファイルで、プログラムが実行中に変更するものをインストールするディレクトリです。通常は /usr/local/com ですが、$(prefix)/com と書きます。(Autoconf を使う場合は「@sharedstatedir@」と書きます。)
プログラムが実行中に変更するデータファイルで、特定の1台のマシンに関わるものをインストールするディレクトリです。パッケージの動作を設定するためにユーザーがこのディレクトリ内のファイルを変更する必要は決して生じないようにすべきです。そうした設定情報は別ファイルにして、$(datadir) か $(sysconfdir) に置いてください。$(localstatedir) は通常 /usr/local/var ですが、$(prefix)/var と書きます。(Autoconf を使う場合は「@localstatedir@」と書きます。)
プログラムが実行中に変更するデータファイルで、特定の1台のマシンに関わり、かつプログラムの実行期間より長く存続する必要のないものをインストールするディレクトリです。ここに置くファイルは一般に長命で、たとえば次回の再起動まで残ります。システムデーモンの PID ファイルが典型的な用途です。さらに、このディレクトリは(再起動時を除いて)掃除されるべきではありませんが、一般的な /tmp(TMPDIR)は任意のタイミングで掃除されてかまいません。通常は /var/run ですが、$(localstatedir)/run と書きます。別の変数として分けてあるのは、たとえば望むなら /run を使えるようにするためです。(Autoconf 2.70 以降を使う場合は「@runstatedir@」と書きます。)
次の変数は、プログラムが持っている場合に、特定の種類のファイルをインストールするディレクトリを指定します。すべての GNU パッケージは Info ファイルを持つべきなので、どのプログラムにも「infodir」が必要ですが、すべてに「libdir」や「lispdir」が必要なわけではありません。
ユーザープログラムが C の「#include」プリプロセッサディレクティブで取り込むためのヘッダファイルをインストールするディレクトリです。通常は /usr/local/include ですが、$(prefix)/include と書きます。(Autoconf を使う場合は「@includedir@」と書きます。)
GCC 以外のほとんどのコンパイラは、/usr/local/include ディレクトリからヘッダファイルを探しません。したがって、この方法でヘッダファイルをインストールするのは GCC を使う場合にしか役立ちません。一部のライブラリは本当に GCC でのみ動くことを意図しているため、これが問題にならないこともあります。しかし、他のコンパイラでも動くことを意図したライブラリもあります。そうしたライブラリは、ヘッダファイルを2か所、すなわち includedir で指定される場所と oldincludedir で指定される場所にインストールすべきです。
GCC 以外のコンパイラで使うための「#include」ヘッダファイルをインストールするディレクトリです。通常は /usr/include です。(Autoconf を使う場合は「@oldincludedir@」と書けます。)
Makefile のコマンドは、oldincludedir の値が空かどうかを確認すべきです。空の場合は、それを使おうとせず、ヘッダファイルの2か所目へのインストールを取りやめるべきです。
パッケージは、このディレクトリにある既存のヘッダを、それが同じパッケージ由来のものでない限り、置き換えるべきではありません。したがって、あなたの Foo パッケージが foo.h というヘッダファイルを提供する場合、(1) oldincludedir に foo.h が存在しないか、(2) そこに存在する foo.h が Foo パッケージ由来のものである、のどちらかであれば、ヘッダファイルを oldincludedir ディレクトリにインストールすべきです。
foo.h が Foo パッケージ由来かどうかを見分けるには、そのファイルの中に(コメントの一部として)目印になる特別な文字列を入れておき、その文字列を grep で探します。
このパッケージの(Info 以外の)ドキュメントファイルをインストールするディレクトリです。デフォルトでは /usr/local/share/doc/yourpkg にすべきですが、$(datarootdir)/doc/yourpkg と書きます。(Autoconf を使う場合は「@docdir@」と書きます。)yourpkg サブディレクトリ(バージョン番号を含めてもよい)は、README のようなありふれた名前を持つファイル同士の衝突を防ぎます。
このパッケージの Info ファイルをインストールするディレクトリです。デフォルトでは /usr/local/share/info にすべきですが、$(datarootdir)/info と書きます。(Autoconf を使う場合は「@infodir@」と書きます。)infodir が docdir と別になっているのは、既存の慣行との互換性のためです。
それぞれ特定の形式のドキュメントファイルをインストールするディレクトリです。デフォルトではすべて $(docdir) に設定すべきです。(Autoconf を使う場合は「@htmldir@」「@dvidir@」などと書きます。)ドキュメントの複数の翻訳を提供するパッケージは、それらを「$(htmldir)/」ll、「$(pdfdir)/」ll などにインストールすべきです。ここで ll は「en」や「pt_BR」のようなロケールの略号です。
オブジェクトファイルや、オブジェクトコードのライブラリを置くディレクトリです。実行可能ファイルはここにインストールしないでください。それらはおそらく代わりに $(libexecdir) に置くべきです。libdir の値は通常 /usr/local/lib ですが、$(exec_prefix)/lib と書きます。(Autoconf を使う場合は「@libdir@」と書きます。)
このパッケージ内の Emacs Lisp ファイルをインストールするディレクトリです。デフォルトでは /usr/local/share/emacs/site-lisp にすべきですが、$(datarootdir)/emacs/site-lisp と書きます。
Autoconf を使う場合は、デフォルトを「@lispdir@」と書きます。「@lispdir@」を機能させるには、configure.ac ファイルに次の行が必要です:
lispdir='${datarootdir}/emacs/site-lisp'
AC_SUBST(lispdir)
このパッケージのロケール固有のメッセージカタログをインストールするディレクトリです。デフォルトでは /usr/local/share/locale にすべきですが、$(datarootdir)/locale と書きます。(Autoconf を使う場合は「@localedir@」と書きます。)このディレクトリは通常、ロケールごとにサブディレクトリを持ちます。
Unix 形式の man ページは、次のいずれかにインストールします:
このパッケージの man ページ(があれば)をインストールする最上位ディレクトリです。通常は /usr/local/share/man ですが、$(datarootdir)/man と書くべきです。(Autoconf を使う場合は「@mandir@」と書きます。)
セクション1の man ページをインストールするディレクトリです。$(mandir)/man1 と書きます。
セクション2の man ページをインストールするディレクトリです。$(mandir)/man2 と書きます。
GNU ソフトウェアの主たるドキュメントを man ページにしてはいけません。代わりに Texinfo でマニュアルを書いてください。man ページは、GNU ソフトウェアを Unix 上で動かす人のためだけのものであり、それは副次的な用途にすぎません。
インストールされる man ページのファイル名の拡張子です。これはピリオドに続けて適切な数字を含むべきで、通常は「.1」にします。
インストールされるセクション1の man ページのファイル名の拡張子です。
インストールされるセクション2の man ページのファイル名の拡張子です。
パッケージがマニュアルの複数のセクションに man ページをインストールする必要がある場合は、「manext」の代わりにこれらの名前を使ってください。
そして最後に、次の変数を設定すべきです:
コンパイル対象のソースが置かれているディレクトリです。この変数の値は、通常 configure シェルスクリプトによって挿入されます。(Autoconf を使う場合は「srcdir = @srcdir@」とします。)
例を挙げます:
# Common prefix for installation directories. # NOTE: This directory must exist when you start the install. prefix = /usr/local datarootdir = $(prefix)/share datadir = $(datarootdir) 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 = $(datarootdir)/info
プログラムが、標準のユーザー指定ディレクトリのいずれかに多数のファイルをインストールする場合は、それらをそのプログラム専用のサブディレクトリにまとめておくと便利かもしれません。そうする場合は、それらのサブディレクトリを作成するように install ルールを書くべきです。
上に挙げた変数のいずれの値にも、ユーザーがサブディレクトリ名を含めるとは期待しないでください。インストール先ディレクトリの変数名を統一しておくという考え方は、ユーザーが複数の異なる GNU パッケージに対してまったく同じ値を指定できるようにするためのものです。これが役に立つためには、ユーザーがそうしたときに、すべてのパッケージが筋の通った動作をするように設計されていなければなりません。
現行リリースの Autoconf や Automake では、これらの変数のすべてが実装されているとは限らないこともあります。ただし Autoconf 2.60 以降では、すべて実装されていると考えています。実装されていないものがある場合、ここでの説明は Autoconf が実装すべき内容の仕様として機能します。プログラマとしては、開発版の Autoconf を使うか、それらの変数をサポートする安定版がリリースされるまで使用を控えるか、いずれかを選べます。
すべての GNU プログラムは、その Makefile に次のターゲットを持つべきです:
プログラム全体をコンパイルします。これがデフォルトのターゲットであるべきです。このターゲットでドキュメントファイルを再生成する必要はありません。Info ファイルは通常配布物に含まれているべきですし、DVI(やその他のドキュメント形式)のファイルは、明示的に求められたときにだけ作るべきです。
デフォルトでは、Make のルールは「-g」付きでコンパイルとリンクを行い、実行可能プログラムにデバッグ用シンボルが入るようにすべきです。そうしておかないと、クラッシュに直面したときに本質的になす術がなくなりますし、新たにビルドし直しても再現するのが容易でないことがしばしばあるからです。
プログラムをコンパイルし、実行可能ファイルやライブラリなどを、実際に使うときに置かれるべきファイル名の場所へコピーします。プログラムが正しくインストールされたかを確かめる簡単なテストがあるなら、このターゲットでそのテストを実行すべきです。
インストールするときに実行可能ファイルを strip(シンボル削除)してはいけません。これは、後で必要になるかもしれないデバッグの助けになります。また、今どきはディスク容量も安価ですし、動的ローダはたいてい通常の実行時にデバッグ用セクションが読み込まれないようにしてくれます。strip された実行ファイルが必要なユーザーは、install-strip ターゲットを起動すればよいのです。
可能であれば、「make all」を済ませた直後であれば、install ターゲットのルールがプログラムをビルドしたディレクトリ内のものを何も変更しないように書いてください。これは、あるユーザー名でプログラムをビルドし、別のユーザー名でインストールするときに便利です。
コマンドは、ファイルをインストールするためのディレクトリがまだ存在しないなら、それらをすべて作成すべきです。これには、prefix と exec_prefix という変数の値として指定されたディレクトリだけでなく、必要となるすべてのサブディレクトリも含まれます。これを行う方法の1つが、後述する installdirs ターゲットを使うことです。
man ページをインストールするコマンドの前には「-」を付けて、make がエラーを無視するようにしてください。これは、Unix の man ページのドキュメントシステムがインストールされていないシステムに備えるためです。
Info ファイルをインストールする方法は、$(INSTALL_DATA) を使ってそれらを $(infodir) にコピーし(コマンドを指定するための変数を参照してください)、その後 install-info プログラムがあればそれを実行する、というものです。install-info は、Info の dir ファイルを編集して、与えられた Info ファイルのメニュー項目を追加・更新するプログラムで、Texinfo パッケージの一部です。
次に、Info ファイルをインストールするルールのサンプルを示します。これは、install-info が存在しない場合など、いくつかの追加的な状況にも対処しようとしています。
do-install-info: foo.info installdirs
$(NORMAL_INSTALL)
# Prefer an info file in . to one in srcdir.
if test -f foo.info; then d=.; \
else d="$(srcdir)"; fi; \
$(INSTALL_DATA) $$d/foo.info \
"$(DESTDIR)$(infodir)/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.
# Use '$(SHELL) -c' because some shells do not
# fail gracefully when there is an unknown command.
$(POST_INSTALL)
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つの分類、すなわち通常のコマンド・インストール前(pre-installation)コマンド・インストール後(post-installation)コマンドに分類しなければなりません。インストールコマンドの分類を参照してください。
これらのターゲットは、Info 以外の形式のドキュメントをインストールします。これらは、その形式が望まれる場合に、パッケージをインストールする人が明示的に呼び出すことを想定しています。GNU は Info ファイルを好むため、Info は install ターゲットでインストールしなければなりません。
インストールするドキュメントファイルが多数ある場合は、衝突や散らかりを避けるために、これらのターゲットが htmldir などの適切なインストール先ディレクトリのサブディレクトリにインストールするように仕組むことをお勧めします。一例として、パッケージが複数のマニュアルを持ち、多数のファイルからなる HTML ドキュメント(たとえば makeinfo --html が出力する「分割」モードのもの)をインストールしたい場合、まず間違いなくサブディレクトリを使いたくなるはずです。そうしないと、異なるマニュアル内の同名の2つのノードが互いを上書きしてしまいます。
これらの install-format ターゲットは、たとえば format を前提条件にするなどして、format ターゲットのコマンドを呼び出すようにしてください。
インストールされたすべてのファイル、すなわち「install」や「install-*」ターゲットが作成したコピーを削除します。
このルールは、コンパイルが行われたディレクトリを変更すべきではなく、ファイルがインストールされたディレクトリだけを対象とすべきです。
アンインストールのコマンドは、インストールのコマンドと同様に3つに分類されます。インストールコマンドの分類を参照してください。
install と同様ですが、実行可能ファイルをインストールするときに strip します。単純な場合には、このターゲットは install ターゲットを次のように簡単に利用できます:
install-strip:
$(MAKE) INSTALL_PROGRAM='$(INSTALL_PROGRAM) -s' \
install
しかし、パッケージが本物の実行可能ファイルだけでなくスクリプトもインストールする場合、install-strip ターゲットは単に install ターゲットを参照するだけというわけにはいきません。実行可能ファイルは strip しつつ、スクリプトは strip しないようにしなければならないからです。
install-strip は、インストールのためにコピーされる、ビルドディレクトリ内の実行可能ファイルを strip すべきではありません。strip すべきなのは、インストールされたコピーだけです。
通常、プログラムにバグがないと確信できる場合を除いて、実行可能ファイルを strip することはお勧めしません。ただし、バグがあったときに備えて strip されていない実行ファイルを別の場所に保存しておきつつ、実際の実行用には strip された実行ファイルをインストールする、というのは妥当な場合もあります。
プログラムをビルドする過程で通常作られる、カレントディレクトリ内のすべてのファイルを削除します。この makefile によって他のディレクトリに作られたファイルも削除します。ただし、設定(configure)の結果を記録するファイルは削除しないでください。また、ビルドによって作ることはできるものの、配布物に同梱されているために通常は作られないファイルも残してください。「mkdir -p」で作られた親ディレクトリを削除する必要はありません。そうしたディレクトリはいずれにせよ元から存在していた可能性があるからです。
.dvi ファイルが配布物に含まれない場合は、ここで削除します。
プログラムの設定(configure)やビルドによって作られる、カレントディレクトリ内の(またはこの makefile によって作られた)すべてのファイルを削除します。ソースを展開し、他のファイルをいっさい作らずにプログラムをビルドしたのであれば、「make distclean」を実行すると配布物に含まれていたファイルだけが残るはずです。ただし、「mkdir -p」で作られた親ディレクトリを削除する必要はありません。そうしたディレクトリはいずれにせよ元から存在していた可能性があるからです。
「clean」に似ていますが、人が通常は再コンパイルしたくないであろう少数のファイルについては、削除を控えてもかまいません。たとえば GCC の「mostlyclean」ターゲットは libgcc.a を削除しません。これを再コンパイルする必要はめったになく、しかも多くの時間がかかるからです。
この Makefile で再構築できるものを、ほぼすべて削除します。これには通常、distclean で削除されるものすべてに加えて、さらに多くのもの、すなわち Bison が生成した C ソースファイル、tags テーブル、Info ファイルなどが含まれます。
「ほぼすべて」と言うのには理由があります。「make maintainer-clean」というコマンドを実行しても、たとえ Makefile 内のルールで configure を作り直せるとしても、configure を削除すべきではないからです。もっと一般的に言えば、「make maintainer-clean」は、configure を実行してからプログラムのビルドを始めるために存在している必要のあるものを、何も削除すべきではありません。また、「mkdir -p」で作られた親ディレクトリを削除する必要もありません。そうしたディレクトリはいずれにせよ元から存在していた可能性があるからです。これらが唯一の例外で、maintainer-clean は再ビルドできる他のすべてを削除すべきです。
「maintainer-clean」ターゲットは、一般のユーザーではなく、パッケージの保守担当者(maintainer)が使うことを意図しています。「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: foo.info
foo.info: foo.texi chap1.texi chap2.texi
$(MAKEINFO) $(srcdir)/foo.texi
Makefile では変数 MAKEINFO を定義しなければなりません。これは makeinfo プログラムを実行すべきもので、makeinfo は Texinfo 配布物の一部です。
通常、GNU の配布物には Info ファイルが同梱されており、つまり Info ファイルはソースディレクトリに存在します。したがって、Info ファイルの Make ルールは、それをソースディレクトリで更新すべきです。ユーザーがパッケージをビルドするとき、Info ファイルはすでに最新の状態であるため、Make は通常 Info ファイルを更新しません。
指定された形式のドキュメントファイルを生成します。これらのターゲットは常に存在すべきですが、その出力形式が生成できない場合は、いずれも(あるいはすべてが)何もしない(no-op)ものであってかまいません。これらのターゲットを all ターゲットの前提条件にすべきではありません。ユーザーが手動で起動するようにします。
次に、Texinfo から DVI ファイルを生成するルールの例を示します:
dvi: foo.dvi
foo.dvi: foo.texi chap1.texi chap2.texi
$(TEXI2DVI) $(srcdir)/foo.texi
Makefile では変数 TEXI2DVI を定義しなければなりません。これは texi2dvi プログラムを実行すべきもので、texi2dvi は Texinfo 配布物の一部です。(texi2dvi は組版という実際の作業を TeX を使って行います。TeX は Texinfo には同梱されていません。)あるいは、前提条件だけを書いて、コマンドは GNU make に提供させてもかまいません。
もう1つ、Texinfo から HTML を生成する例を示します:
html: foo.html
foo.html: foo.texi chap1.texi chap2.texi
$(TEXI2HTML) $(srcdir)/foo.texi
この場合も、Makefile では変数 TEXI2HTML を定義します。たとえば makeinfo --no-split --html を実行するようにします(makeinfo は Texinfo 配布物の一部です)。
このプログラムの配布用 tar ファイルを作成します。tar ファイルは、その中のファイル名が、配布対象であるパッケージの名前であるサブディレクトリ名から始まるように作るべきです。この名前にはバージョン番号を含めてもかまいません。
たとえば、GCC バージョン 1.40 の配布用 tar ファイルは、gcc-1.40 という名前のサブディレクトリに展開されます。
これを行ういちばん簡単な方法は、適切な名前のサブディレクトリを作り、ln や cp を使って必要なファイルをそこにインストールし、そのサブディレクトリを tar でまとめることです。
tar ファイルは gzip で圧縮します。たとえば、GCC バージョン 1.40 の実際の配布ファイルは gcc-1.40.tar.gz という名前です。他のフリーな圧縮形式もあわせてサポートしてかまいません。
dist ターゲットは、配布物に含まれるソース以外のすべてのファイルに明示的に依存させて、配布物の中でそれらが最新の状態になっているようにすべきです。GNU Coding Standards の Making Releases の項を参照してください。
(もしあれば)自己テストを実行します。ユーザーはテストを実行する前にプログラムをビルドしなければなりませんが、インストールする必要はありません。自己テストは、プログラムがビルドされていればインストールされていなくても動くように書くべきです。
次のターゲットは、それらが役に立つプログラムに向けて、慣習的な名前として提案するものです。
installcheck(もしあれば)インストールのテストを実行します。ユーザーはテストを実行する前にプログラムをビルドしてインストールしなければなりません。$(bindir) が探索パスに含まれていると思い込んではいけません。
installdirsファイルがインストールされるディレクトリとその親ディレクトリを作成するため、「installdirs」という名前のターゲットを追加しておくと便利です。これには mkinstalldirs という便利なスクリプトがあります。Gnulib パッケージの中にあります。次のようなルールを使えます:
# 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)
このルールは、コンパイルが行われるディレクトリを変更すべきではありません。インストール先ディレクトリを作成する以外、何もすべきではありません。
install ターゲットを書くときは、すべてのコマンドを3つの分類、すなわち通常のコマンド・インストール前(pre-installation)コマンド・インストール後(post-installation)コマンドに分類しなければなりません。
通常のコマンドは、ファイルを本来あるべき場所へ移動し、そのモード(パーミッション)を設定します。これらは、所属するパッケージから完全に由来するファイル以外のものを変更してはいけません。
インストール前・インストール後のコマンドは、他のファイルを変更してもかまいません。とりわけ、グローバルな設定ファイルやデータベースを編集することができます。
インストール前のコマンドは通常、通常のコマンドより前に実行され、インストール後のコマンドは通常、通常のコマンドより後に実行されます。
インストール後のコマンドの最も一般的な用途は、install-info の実行です。これは通常のコマンドでは行えません。なぜなら、これは、インストールされるパッケージから完全かつ専一に由来するわけではないファイル(Info ディレクトリ)を変更するからです。これがインストール後のコマンドであるのは、パッケージの Info ファイルをインストールする通常のコマンドの後に実行される必要があるからです。
ほとんどのプログラムはインストール前のコマンドを必要としませんが、念のため、必要になった場合に備えてこの機能を用意しています。
install ルール内のコマンドをこれら3つに分類するには、それらの間に分類行(category line)を挿入します。分類行は、それに続くコマンドの分類を指定します。
分類行は、タブと、特別な Make 変数への参照、それに末尾の任意のコメントから構成されます。各分類に1つずつ、計3つの変数を使えます。変数名が分類を指定します。これら3つの Make 変数は通常未定義なので(そして makefile の中でこれらを定義すべきではありません)、分類行は通常の実行では何もしません(no-op)。
次に、ありうる3つの分類行を、それぞれの意味を説明するコメントとともに示します:
$(PRE_INSTALL) # インストール前のコマンドが続く。
$(POST_INSTALL) # インストール後のコマンドが続く。
$(NORMAL_INSTALL) # 通常のコマンドが続く。
install ルールの先頭に分類行を置かなかった場合、最初の分類行までのすべてのコマンドは通常のコマンドとして分類されます。分類行をいっさい使わなかった場合は、すべてのコマンドが通常のコマンドとして分類されます。
uninstall のための分類行は次のとおりです:
$(PRE_UNINSTALL) # アンインストール前のコマンドが続く。
$(POST_UNINSTALL) # アンインストール後のコマンドが続く。
$(NORMAL_UNINSTALL) # 通常のコマンドが続く。
典型的には、アンインストール前のコマンドは Info ディレクトリから項目を削除するために使われます。
install や uninstall のターゲットが、インストールのサブルーチンとして働く前提条件を持つ場合は、その各前提条件のコマンドを分類行で始め、さらに主ターゲットのコマンドも分類行で始めるべきです。こうすれば、前提条件のうちどれが実際に実行されても、各コマンドが正しい分類に置かれることを保証できます。
インストール前・インストール後のコマンドは、次のプログラム以外を実行すべきではありません:
[ basename bash cat chgrp chmod chown cmp cp dd diff echo expand expr false 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 の -s オプションは、サブディレクトリに入る旨のメッセージを抑制するために必要です):
make -s -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 ~ /^(normal-install|post-install)[ \t]*$/ {on = 0}
on {print $0}
$0 ~ /^pre-install[ \t]*$/ {on = 1}