• Introduction: Autoconfの目的、利点と欠点。
• Making configure Scripts: Autoconfスクリプトの準備・作成方法。
• Setup: Initialization and output.
• Existing Tests: Macros that check for particular features.
• Writing Tests: How to write new feature checks.
• Results: What to do with results from feature checks.
• Writing Macros: Adding new macros to Autoconf.
• Manual Configuration: Selecting features that can't be guessed.
• Site Configuration: Local defaults for configure.
• Invoking configure: How to use the Autoconf output.
• Invoking config.status: Recreating a configuration.
• Questions: Questions about Autoconf, with answers.
• Upgrading: Tips for upgrading from version 1.
• History: History of Autoconf.
• Old Macro Names: Backward compatibility macros.
• Environment Variable Index: Index of environment variables used.
• Output Variable Index: Index of variables set in output files.
• Preprocessor Symbol Index: Index of C preprocessor symbols defined.
• Macro Index: Index of Autoconf macros.

  --- The Detailed Node Listing ---

  Making configure Scripts

• Writing configure.in: What to put in an Autoconf input file.
• Invoking autoscan: Semi-automatic configure.in writing.
• Invoking ifnames: Listing the conditionals in source code.
• Invoking autoconf: How to create configuration scripts.
• Invoking autoreconf: Remaking multiple configure scripts.

  Initialization and Output Files

• Input: Where Autoconf should find files.
• Output: Creating output files.
• Makefile Substitutions: Using output variables in Makefiles.
• Configuration Headers: Creating a configuration header file.
• Subdirectories: Configuring independent packages together.
• Default Prefix: Changing the default installation prefix.
• Versions: Version numbers in configure.

  Substitutions in Makefiles

• Preset Output Variables: Output variables that are always set.
• Build Directories: Supporting multiple concurrent compiles.
• Automatic Remaking: Makefile rules for configuring.

  Configuration Header Files

• Header Templates: Input for the configuration headers.
• Invoking autoheader: How to create configuration templates.

  Existing Tests

• Alternative Programs: Selecting between alternative programs.
• Libraries: Library archives that might be missing.
• Library Functions: C library functions that might be missing.
• Header Files: Header files that might be missing.
• Structures: Structures or members that might be missing.
• Typedefs: typedefs that might be missing.
• C Compiler Characteristics:
• Fortran 77 Compiler Characteristics:
• System Services: Operating system services.
• UNIX Variants: Special kludges for specific UNIX variants.

  Alternative Programs

• Particular Programs: Special handling to find certain programs.
• Generic Programs: How to find other programs.

  Library Functions

• Particular Functions: Special handling to find certain functions.
• Generic Functions: How to find other functions.

  Header Files

• Particular Headers: Special handling to find certain headers.
• Generic Headers: How to find other headers.

  Typedefs

• Particular Typedefs: Special handling to find certain types.
• Generic Typedefs: How to find other types.

  Writing Tests

• Examining Declarations: Detecting header files and declarations.
• Examining Syntax: Detecting language syntax features.
• Examining Libraries: Detecting functions and global variables.
• Run Time: Testing for run-time features.
• Portable Shell: Shell script portability pitfalls.
• Testing Values and Files: Checking strings and files.
• Multiple Cases: Tests for several possible values.
• Language Choice: Selecting which language to use for testing.

  Checking Run Time Behavior

• Test Programs: Running test programs.
• Guidelines: General rules for writing test programs.
• Test Functions: Avoiding pitfalls in test programs.

  Results of Tests

• Defining Symbols: Defining C preprocessor symbols.
• Setting Output Variables: Replacing variables in output files.
• Caching Results: Speeding up subsequent configure runs.
• Printing Messages: Notifying users of progress or problems.

  Caching Results

• Cache Variable Names: Shell variables used in caches.
• Cache Files: Files configure uses for caching.

  Writing Macros

• Macro Definitions: Basic format of an Autoconf macro.
• Macro Names: What to call your new macros.
• Quoting: Protecting macros from unwanted expansion.
• Dependencies Between Macros: What to do when macros depend on other macros.

  Dependencies Between Macros

• Prerequisite Macros: Ensuring required information.
• Suggested Ordering: Warning about possible ordering problems.
• Obsolete Macros: Warning about old ways of doing things.

  Manual Configuration

• Specifying Names: Specifying the system type.
• Canonicalizing: Getting the canonical system type.
• System Type Variables: Variables containing the system type.
• Using System Type: What to do with the system type.

  Site Configuration

• External Software: Working with other optional software.
• Package Options: Selecting optional features.
• Site Details: Configuring site details.
• Transforming Names: Changing program names when installing.
• Site Defaults: Giving configure local defaults.

  Transforming Program Names When Installing

• Transformation Options: configure options to transform names.
• Transformation Examples: Sample uses of transforming names.
• Transformation Rules: Makefile uses of transforming names.

  Running configure Scripts

• Basic Installation: Instructions for typical cases.
• Compilers and Options: Selecting compilers and optimization.
• Multiple Architectures: Compiling for multiple architectures at once.
• Installation Names: Installing in different directories.
• Optional Features: Selecting optional features.
• System Type: Specifying the system type.
• Sharing Defaults: Setting site-wide defaults for configure.
• Operation Controls: Changing how configure runs.

  Questions About Autoconf

• Distributing: Distributing configure scripts.
• Why GNU m4: Why not use the standard m4?
• Bootstrapping: Autoconf and GNU m4 require each other?
• Why Not Imake: Why GNU uses configure instead of Imake.

  Upgrading From Version 1

• Changed File Names: Files you might rename.
• Changed Makefiles: New things to put in Makefile.in.
• Changed Macros: Macro calls you might replace.
• Invoking autoupdate: Replacing old macro names in configure.in.
• Changed Results: Changes in how to check test results.
• Changed Macro Writing: Better ways to write your own macros.

  History of Autoconf

• Genesis: Prehistory and naming of configure.
• Exodus: The plagues of m4 and Perl.
• Leviticus: The priestly code of portability arrives.
• Numbers: Growth and contributors.
• Deuteronomy: Approaching the promises of easy configuration.

Introduction

物理学者、エンジニアとコンピュータ科学者が神の性質を論じていました。「確
かに物理学者だ」と物理学者が言いました。「なぜなら、創造の早いうちに神が
光を作った。ご存じのように、マックスウェル方程式、電磁波の二重の性質、相
対論者の結果...」。「エンジニアだ!」とエンジニアは言いました。「なぜ
なら、光を作る前に神はカオスを土地と水に分けた。それには大量のエンジニア
が必要で、大量の泥を処理し、液体から固体を正しく分離し...」。コンピュー
タ科学者は叫んだ。「そしてカオス、それはいったいどこからきたと思いますか。
ふーむ?」

---詠み人知らず

Autoconfは、各種UNIX系システムにあわせてソースコードパッケージを 設定(configure)するためのshellスクリプトを自動生成するツールです。 Autoconfによって生成された自動設定スクリプトは、実行されるときには Autoconfとは独立に動きます。このため、自動設定スクリプトのユーザは Autoconfを持っている必要がありません。

Autoconfによって生成される自動設定スクリプトは、ユーザの介入を 必要としません。普通はシステム種別を引数として指定する必要も ありません。引数を求めたりするかわりに、ソフトウェアパッケージが使う 可能性のあるOSの機能が存在するかどうかがひとつづつチェックされます。 (各チェックの前に、何をチェックしているのかが1行メッセージとして 表示されます。このため、ユーザはスクリプトの実行を待っている間さほど 退屈せずにすみます) 結果として、ターゲットが通常のUNIX系のOSよりもカスタマイズされていたり、 (BSD系とSVR4系の)融合されたOSだったりしても、スクリプトはターゲットOSを うまく扱うことができます。各々のUNIX系OSについて、どの機能がサポート されているかをファイルに記録したりする必要はありません。

Autoconfは、Autoconfを用いる各ソフトウェアパッケージについて、 自動設定スクリプトを作成します。自動設定スクリプトは各パッケージが 必要とする、または用いることのできるOSの機能を並べた テンプレートファイルから生成されます。 OSの機能を検出して反応するshellスクリプトが書けたなら、 Autoconfはそのshellスクリプトを複数のソフトウェアパッケージで 共有する機構を持っています。もし後でshellスクリプトを修正する 必要が生じた場合でも、定義を1箇所だけ変更すればいいようになっています。 各ソフトウェアパッケージの自動生成スクリプトを再生成すれば、 shellスクリプトへの修正が反映されます。

MetaconfigパッケージはAutoconfと似た目的をもっていますが、 Metaconfigによって生成されるスクリプトはユーザの介入を必要とし、 大きなソースツリーを設定する場合には不便です。 Metaconfigの生成するスクリプトと違い、Autoconfはクロスコンパイルの 設定も扱うことができます(設定ファイルを注意深く書けば)。

移植性の高いソフトウェアパッケージを作るためには、Autoconfの してくれないことがいくつか必要になります。例えば、各ターゲット プログラムのためのMakefileの自動生成や、システムに欠けている 標準ライブラリ関数やヘッダファイルを補う、などです。これらを自動化 するための作業は現在進行中です。

Autoconfを使う場合、C言語のプログラムで#ifdefして使うシンボルの 名前に一部制限が生じます(see Preprocessor Symbol Index)。

Autoconfはスクリプトの生成のためにGNU m4を必要とします。 Autoconfは一部のUNIXについてくるm4にはない機能を使っています。 また、Autoconfは(GNU m4 1.0を含む)一部のバージョンのm4の 内部制限を越えてしまう場合があります。 Autoconfと一緒には、GNU m4 1.1以降を使う必要があります。 バージョン1.3あるいはそれ以降を使った場合、1.1や1.2を使う場合より 大幅に高速になります。

バージョン1からのアップグレードのためにはSee Upgradingを 参照してください。 Autoconfの開発経緯についてはSee Historyを参照してください。 Autoconfに関する質問集はSee Questionsを参照してください。

Autoconfに関する御意見やバグレポートは bug-gnu-utils@prep.ai.mit.eduまでmailでお寄せください。 Autoconfのバージョン番号を書くのを忘れずに。 バージョン番号はautoconf --versionで調べられます。

訳註: この和訳版は伊藤いとぢゅん純一郎 (itojun@itojun.org)に よるものです。 訳し間違いがあっても、犬も食いません。 疑問点があったら、「必ず原文を参照する」ようにしてください。 再配布などについては原文に従います。

訳註: この和訳版のAutoconf version 2.12 -> 2.13 へのマージ作業を新井康司 jca02266@nifty.ne.jpが行いました。一部、翻訳も行いました。訳が おかしな所は新井の担当部分です:-)

Making configure Scripts

Autoconfによって生成される自動設定スクリプトは、configureと 呼ばれることになってます。configureは実行されると、 設定パラメタを適切な値に書き換えながらいくつかのファイルを作成します。 configureが生成するファイルは以下のとおりです:

• ひとつまたは複数(パッケージ中の各サブディレクトリ にひとつづつ)のMakefile。 (see Makefile Substitutions)
• オプションで指定された場合、#define ディレクティブを含むCヘッダファイル。 ファイル名は設定で変えられます。 (see Configuration Headers)
• config.statusという名前のshellスクリプト。 このスクリプトを実行すると、上記のファイルが 再生成されます。 (see Invoking config.status)
• config.cacheという名前のshellスクリプト。 たくさんのテスト結果を保存するファイルです。 (see Cache Files)
• コンパイラが出力したメッセージを記録する config.logファイル。 configureがうまく動かなかった場合の デバッグに使います。

Autoconfを使ってconfigureスクリプトを作成するためには、 Autoconfの入力ファイルconfigure.inを作り、autoconfを 実行する必要があります。Autoconfに標準でついてくるものを補うために、 OSの機能をチェックするための自作のshellスクリプトを書いた場合には、 それをaclocal.m4とacsite.m4に書いておくとよいでしょう。 #defineディレクティブを含むCヘッダファイルを使うなら、 acconfig.hを作成する必要があるかもしれません。 さらに、Autoconfの生成したconfig.h.inをパッケージとともに 配布することになります。

以下の図は、自動設定が行われるときにどのようにファイルが用いられる のかを示しています。実行されるプログラム名には*がつけてあります。 なくてもいいファイルは角カッコ([])でかこんであります。 autoconfとautoheaderは、下図に加えてAutoconfマクロファイルを 読み込みます(autoconf.m4のことです)。

配布用ソフトウェアパッケージの作成時に使われるファイル:

your source files --> [autoscan*] --> [configure.scan] --> configure.in

configure.in --.   .------> autoconf* -----> configure
               +---+
[aclocal.m4] --+   `---.
[acsite.m4] ---'       |
                       +--> [autoheader*] -> [config.h.in]
[acconfig.h] ----.     |
                 +-----'
[config.h.top] --+
[config.h.bot] --'

Makefile.in -------------------------------> Makefile.in

ソフトウェアパッケージの設定時に使われるファイル:

                       .-------------> config.cache
configure* ------------+-------------> config.log
                       |
[config.h.in] -.       v            .-> [config.h] -.
               +--> config.status* -+               +--> make*
Makefile.in ---'                    `-> Makefile ---'

• Writing configure.in: What to put in an Autoconf input file.
• Invoking autoscan: Semi-automatic configure.in writing.
• Invoking ifnames: Listing the conditionals in source code.
• Invoking autoconf: How to create configuration scripts.
• Invoking autoreconf: Remaking multiple configure scripts.

Writing configure.in

あるソフトウェアパッケージ用のconfigureスクリプトを 生成するためには、configure.inという名前のファイルを 作成する必要があります。このファイルには、ソフトウェアパッケージが 必要とする、または使う事のできるOSの機能をチェックするための Autoconfマクロの呼出列が記述されます。 たくさんの機能をチェックするために、Autoconfマクロとして既に たくさんのものが準備されています。Existing Testsを 参照してください。 AutoconfマクロのないOSの機能でも、多くの場合には特製チェックルーチンを 作るのにAutoconfテンプレートマクロを使うことができます。 Writing Testsを参照してください。 特にトリッキー、または特殊なOS機能のチェックをする場合、 configure.inに手でshellコマンド列を書かないといけないかも しれません。 autoscanプログラムを使うと、configure.inを 書きはじめるための元ファイルを自動生成してくれます(より詳しくは see Invoking autoscanを参照)。

configure.inの中でAutoconfマクロを呼び出す順番は、一部の例外を 除けば重要ではありません。configure.inファイルにはAC_INIT マクロの呼び出しが一番最初に、AC_OUTPUTマクロの呼び出しが 一番最後に入っている必要があります(see Output参照)。 さらに、一部のマクロは先に呼ばれる他のマクロに依存しています。 先に呼ばれるマクロによって設定される値によって動作を変えるためです。 このようなマクロはそれぞれのマクロの説明に注意書きがしてあります (see Existing Tests参照)し、もし逆順に呼んだ場合、configureの 生成時に警告が出ます。

configure.inに統一性をもたせるため、以下の順でAutoconfマクロを 呼ぶことを推奨します。一般にいって、最後の方に書かれているものは 先にあるものに依存しています。例えば、ライブラリ関数のチェックは typedefとライブラリファイルのチェック結果に依存します。

AC_INIT(file)
checks for programs
checks for libraries
checks for header files
checks for typedefs
checks for structures
checks for compiler characteristics
checks for library functions
checks for system services
AC_OUTPUT([file...])

configure.inに、1行にひとつづつマクロの呼び出しを記述することを お勧めします。ほとんどのマクロは、余計な改行を生成しません。すなわち、 マクロ呼び出しの直後の改行があることに頼っています。 このようにすることで、余計な空行がなく、読みやすいconfigure スクリプトを生成することができます。shell変数への代入を マクロ呼び出しとおなじ行で行うのはたいていの場合安全です。 shellスクリプトでは代入文を改行をはさまず記入することができるからです。

引数をとるマクロを呼び出す場合、マクロ名と左括弧の間にスペースを 入れてはいけません。m4のquote文字[と]で 囲むことで、複数行にわたる引数を記述できます。ファイル名の羅列などで 長い行を書かないといけない場合、行末にbackslashを置くことで 論理的な行を続ける(backslashの次の改行を無視させる)ことができます。 これはshellによって実現されているもので、Autoconfが特別なことをしている わけではありません。

マクロには場合分けを含んでいるものがあります: 条件が成立したときに 実行することがらと、条件が成立しなかったときに実行することがらを 記述するような場合です。条件が成立したときにはなにかを実行し、 成立しなかったときにはなにもしないようにしたい(あるいは逆)、ということが あると思います。条件が成立したときになにもしない場合、マクロの 引数action-if-foundに空文字列を渡してください。 条件が成立しなかったときになにもしない場合、マクロの引数 action-if-not-foundを直前のカンマもろとも省略してください。

configure.inにはコメントを含めることができます。 コメントはm4組み込みマクロdnlで始めます。 dnlマクロは次の改行までの文字列を単に無視します。 このようにして書かれたコメントは、configureスクリプトには現れません。 たとえば、configure.inを以下のような行ではじめれば 理解を助けることができるでしょう:

dnl Process this file with autoconf to produce a configure script.

Using autoscan to Create configure.in

autoscanプログラム、あるソフトウェアパッケージのための configure.inを生成する際に役立ちます。autoscanは コマンドライン引数で指定されたディレクトリ(指定されなかった場合 カレントディレクトリ)以下のソースファイルについて、移植性に 問題のある記述があるかどうかを探します。そして、結果をconfigure.scan というファイルに出力します。このファイルはこのパッケージのための configure.inの雛型として使えます。

configure.scanをconfigure.inにリネームする前に、 内容を確認する必要があります; たぶん手で調整が必要です。 autoscanの出力したconfigure.scanのマクロ列が、 マクロ間の依存関係からみて正しくない順で並んでいる場合があります。 このような場合、autoconfは警告を出力しますので、 マクロの順序を手で変更する必要があります。また、configuration header fileを 使いたい場合、AC_CONFIG_HEADER(see Configuration Headers) マクロの呼び出しを追加する必要があります。さらに、プログラムが Autoconfとうまく動くように、ソースコードの方に#ifディレクティブを 追加する必要があるでしょう(この作業を楽にするためのツールについては see Invoking ifnamesを参照)。

autoscanはいくつかのデータファイルを使って、ソースファイルの中にある シンボルをみつけたときに出力すべきマクロ名を決定します。 このファイルはAutoconfマクロファイルと一緒に配布され、全て おなじフォーマットになっています。ファイルの各行はシンボル、スペース、 シンボルをみつけたときに出力するべきAutoconfのマクロ名、というふうに なっています。#で始まる行はコメントです。

autoscanはPerlがインストールされている場合にのみインストールされます。 autoscanのオプションには以下があります:

--help

コマンドラインオプションの説明を出力して終了します。

--macrodir=dir

デフォルトのインストールディレクトリでなく、 ディレクトリdirにある設定ファイルを 参照します。環境変数AC_MACRODIRを 設定しても同じ効果が得られます。 コマンドラインオプションは環境変数の設定より 優先されます。

--verbose

調べているファイルの名前と、みつけた重要そうな シンボル名を表示します。出力されるメッセージ量は 膨大になる可能性があります。

--version

Autoconfのバージョン番号を出力して終了します。

Using ifnames to List Conditionals

ifnamesはソフトウェアパッケージ用にconfigure.inを書くのを 支援します。ifnamesは、パッケージ中のソースコードで Cプリプロセッサの条件文(#if)に使われている識別子を出力します。 もし、パッケージが既に移植性を高めるように記述されている場合には、 configureでなにをチェックしないといけないか決めるのに使えます。 autoscanの出力を穴うめしてconfigure.inを作成するのにも 役立ちます(see Invoking autoscan)。

ifnamesはコマンドラインに指定されたCソースファイル(なにも 指定されなかったら標準入力)をチェックし、結果を標準出力に出力します。 結果は#if、#elif、#ifdef、または#ifndef の各ディレクティブで使われている識別子をソートして出力します。 各行にはひとつの識別子と、その識別子を使っているファイル名をスペースで 区切ったものが出力されます。

ifnamesは以下のオプションを受け付けます:

--help

-h

コマンドラインオプションの説明を出力して終了します。

--macrodir=dir

-m dir

デフォルトのインストールディレクトリでなく、 ディレクトリdirにある設定ファイルを 参照します。環境変数AC_MACRODIRを 設定しても同じ効果が得られます。 コマンドラインオプションは環境変数の設定より 優先されます。

--version

Autoconfのバージョン番号を出力して終了します。

Using autoconf to Create configure

configure.inからconfigureを生成するためには、 autoconfプログラムをコマンドライン引数なしで実行します。 autoconfはconfigure.inをAutoconfマクロを使って m4マクロプロセッサに通します。autoconfにコマンドライン 引数を与えた場合、configure.inのかわりに引数で指定したファイルが 読み込まれ、結果は標準出力に出力されます(通常はconfigureに結果を 出力します)。-をコマンドライン引数として指定した場合、 configure.inのかわりに標準入力を読み込み、設定スクリプトを 標準出力に出力します。

Autoconfマクロは複数のファイルで定義されます。 autoconfはAutoconfといっしょに配布されているマクロファイルを最初に 読み込みます。次に、Autoconfと一緒に配布されるマクロファイルとおなじ ディレクトリにある、acsite.m4を読み込みます。 その次に、カレントディレクトリにあるaclocal.m4を読み込みます。 各ファイルにはサイト単位の、またはパッケージ単位のAutoconfマクロ定義を 書いておくことができます(マクロの定義法についてはsee Writing Macros 参照)。同じマクロがautoconfが読み込むファイルのうち複数のファイルで 定義されていた場合、あとから読み込まれたものが有効になります。

autoconfは以下のオプションを受け付けます:

--help

-h

コマンドラインオプションの説明を出力して終了します。

--localdir=dir

-l dir

aclocal.m4を探すとき、カレントディレクトリでなしに ディレクトリdirを探しにいきます。

--macrodir=dir

-m dir

デフォルトのインストールディレクトリでなく、 ディレクトリdirにあるAutoconfマクロ ファイルを参照します。環境変数AC_MACRODIRを 設定しても同じ効果が得られます。 コマンドラインオプションは環境変数の設定より 優先されます。

--version

Autoconfのバージョン番号を出力して終了します。

Using autoreconf to Update configure Scripts

Autoconfで生成されたconfigureスクリプトがたくさんある場合、 autoreconfを使うと仕事量を減らせるかもしれません。 autoreconfは、カレントディレクトリ以下のconfigureスクリプトと configuration headerテンプレートを、autoconf(と、必要なら autoheader)を繰り返し起動して再生成します。 デフォルトでは、configure.inと(もしあれば)aclocal.m4よりも 古いファイルのみを再生成します。ただし、これによって行われる作業は 必要最低限の作業とは限りません。これは、autoheaderは出力ファイルの 内容が変化しなかったときにはファイルのタイムスタンプを変更しないためです。 新しいバージョンのAutoconfをインストールした場合、autoreconfに --forceオプションを指定することで、全てのファイルを更新 させることができます。

autoreconfに、--macrodir=dirまたは --localdir=dirのオプションを与えた場合、 これらはautoreconfから呼び出されるautoconfや autoheaderに渡されます。その際、相対パス名は適切に調整されます。

autoreconfは同じディレクトリツリーの中で、(aclocal.m4と acconfig.hを共有する)大きなパッケージの一部であるディレクトリと (自身のaclocal.m4とacconfig.hをそれぞれ持つ)独立したパッケー ジのディレクトリを両方持つことをサポートしません。もし--localdir を使うならすべてが同じパッケージの一部であると仮定し、使わないなら、それ ぞれのディレクトリは分割したパッケージであると仮定します。この制限は将来 なくなるかもしれません。

Makefileのルールで必要なときにconfigureスクリプトを 自動再生成させるためにはSee Automatic Remakingを参照してください。 この方法を使うとconfiguration headerテンプレートのタイムスタンプは きちんと取り扱われますが、--macrodir=dirや --localdir=dirは渡されません。

autoreconfは以下のオプションを受け付けます:

--help

-h

コマンドラインオプションの説明を出力して終了します。

--force

-f

configureスクリプトとconfiguration headerが 入力ファイルより新しい場合でも、これらの再生成を 行います。入力ファイルとはconfigure.inと、もし 存在すればaclocal.m4のことです。

--localdir=dir

-l dir

aclocal.m4を探すとき、カレントディレクトリで なしにディレクトリdirを探しにいきます。 autoheaderを呼び出す場合には、 acconfig.hを探すディレクトリも変わります。 file.topとfile.botに ついては挙動は変わりません。

--macrodir=dir

-m dir

デフォルトのディレクトリでなく、ディレクトリ dirにある Autoconfマクロファイルを参照します。 環境変数AC_MACRODIRを設定しても同じ効果が 得られます。コマンドラインオプションは環境変数の 設定より優先されます。

--verbose

autoreconfからautoconf(と、必要なら autoheader)を呼び出すディレクトリ名を表示します。

--version

Autoconfのバージョン番号を出力して終了します。

Initialization and Output Files

Autoconfで生成されたconfigureスクリプトは、初期化や結果出力の ための情報を必要します。たとえば、パッケージのソースファイルは どこにあるのかとか、どのような出力ファイルを生成すべきか、などです。 以下の節では、初期化と結果出力について説明します。

• Input: Where Autoconf should find files.
• Output: Creating output files.
• Makefile Substitutions: Using output variables in Makefiles.
• Configuration Headers: Creating a configuration header file.
• Subdirectories: Configuring independent packages together.
• Default Prefix: Changing the default installation prefix.
• Versions: Version numbers in configure.

Finding configure Input

configureスクリプトは他の全てのマクロより先に、AC_INIT マクロを呼び出さねばなりません。必ず呼び出されなければならないマクロは AC_INITとAC_OUTPUTだけです(see Output)。

AC_INIT (unique-file-in-source-dir)

Macro

コマンドライン引数を処理し、ソースコードの置かれている ディレクトリをみつけます。unique-file-in-source-dirは パッケージのソースコードの置かれたディレクトリにある、 任意のファイルの名前です; configureは、指定された ディレクトリにソースコードが実際あるかどうか、 そのファイルが存在するかどうかを調べることで判断します。 ときには、ユーザはコマンドラインオプション--srcdirで 間違ったディレクトリを指定するかもしれません; この判定は、 安全のためのチェックです。詳しくはSee Invoking configureを 参照してください。

手動で設定を行うパッケージや、installプログラムを 利用するパッケージでは、AC_CONFIG_AUX_DIRを使って、 configureに他のshellスクリプトがどこにあるかを 知らせる必要があるかもしれません。たいていはデフォルトで 調べにいく場所で正しいのですが。

AC_CONFIG_AUX_DIR(dir)

Macro

ディレクトリdirに格納されている install-sh、config.sub、 config.guess、それからCygnus configureスクリプトを利用することを 指定します。dirは絶対パス、または srcdirからの相対パスで指定します。 デフォルトはsrcdirまたは srcdir/..または srcdir/../..のうち、 install-shが最初にみつかった場所です。 他のファイルの置き場所についてはチェックが 行われません。これはAC_PROG_INSTALLを 使っただけで他のファイルを配布しなければ ならなくなるのを防ぐためです。 このマクロはinstall.shもチェックしますが、 このファイル名はobsoleteです。なぜなら、 Makefileがない場合、makeが組み込み ルールを使ってinstall.shからinstallを 生成しようとするからです。

Creating Output Files

Autoconfで生成されたconfigureスクリプトは、 最後にAC_OUTPUTを呼び出さねばなりません。 このマクロは、Makefileや他のファイルを自動設定結果にしたがって 生成します。configure.inに必ず含まれなければならない マクロは、AC_OUTPUTの他にはAC_INITだけです(see Input)。

AC_OUTPUT ([file... [, extra-cmds [, init-cmds]]])

Macro

出力ファイルを生成します。このマクロは 1度だけ、configure.inの末尾で 呼び出す必要があります。マクロの 引数file...は、スペースで 区切られた出力ファイル列です; これは空でも構いません。 このマクロは、入力ファイルを fileへ出力変数の値を 置換しながらコピーすることで生成します。 入力ファイルの名前はデフォルトでは file.inです。 出力変数の使い方についてはSee Makefile Substitutionsを 参照してください。出力変数を定めるためには、 See Setting Output Variablesを参照してください。 このマクロは出力先のディレクトリがなければ ディレクトリを作成します(が、さらに親のディレクトリは 作成されません)。通常、このマクロを使って生成する ファイルはMakefileですが、他のファイル、たとえば .gdbinitを生成するのにも使えます。 AC_CONFIG_HEADER、AC_LINK_FILES、または AC_CONFIG_SUBDIRSマクロが呼び出されていた場合、 AC_OUTPUTは各マクロの引数に指定されたファイルも 生成します。 たいてい、AC_OUTPUTは以下のように呼び出されます: AC_OUTPUT(Makefile src/Makefile man/Makefile X/Imakefile) 入力ファイルの名前は、fileのあとにコロンをつけて、 そのあとに入力ファイル名を繋げることで変更できます。 たとえば: AC_OUTPUT(Makefile:templates/top.mk lib/Makefile:templates/lib.mk) AC_OUTPUT(Makefile:templates/vars.mk:Makefile.in:templates/rules.mk) こうすることで、ファイル名をMS-DOSでも使える フォーマットにしたり、ファイルの前後に メッセージ(訳註: boilerplate)をつけたり することができます。 extra-cmdsを指定した場合、指定された コマンドは他の処理の後に実行されるように config.statusに追加されます。 init-cmdsが指定された場合、それは shell変数、コマンド、backslashの 置き換えが行われた後、extra-cmdsの 直前に挿入されます。init-cmdsを 使うことで、configureから extra-cmdsに変数を引き渡すことが できます。AC_OUTPUT_COMMANDSマクロが 呼び出されていた場合、AC_OUTPUT_COMMANDSに 指定されたコマンドは、AC_OUTPUTに指定された コマンドの直前に実行されます。

AC_OUTPUT_COMMANDS (extra-cmds [, init-cmds])

Macro

config.statusの末尾で実行される shellコマンドと、shellコマンド呼び出し前に configureで行うべき変数初期化 手続きを指定します。このマクロは複数回呼び出しても 構いません。実用的でない例題はこんなかんじ: fubar=27 AC_OUTPUT_COMMANDS([echo this is extra $fubar, and so on.], fubar=$fubar) AC_OUTPUT_COMMANDS([echo this is another, extra, bit], [echo init bit])

makeをサブディレクトリで実行する場合には、 変数MAKEを使ってmakeを呼び出さねば なりません。ほとんどのmakeでは、変数 MAKEはmakeプログラムと与えられた オプションに設定されます(が、多くの場合 コマンドラインでの変数値設定は含まれません)。 一部の古いmakeでは、変数MAKEは 設定されません。以下のマクロを使うと、そのような 古いmakeでも変数MAKEを使うことができます。

AC_PROG_MAKE_SET

Macro

makeが変数MAKEを設定しているなら、 変数SET_MAKEを空にします。 そうでない場合、SET_MAKEをMAKE=makeに 設定します。内部でAC_SUBSTを SET_MAKEを置換するように呼び出します。

このマクロを利用する場合、MAKEを利用する 各々のMakefile.inに以下のような行を置いてください:

@SET_MAKE@

Substitutions in Makefiles

配布パッケージの各サブディレクトリのうちでコンパイルやインストールが 必要なディレクトリには、Makefile.inを置きます。 configureはMakefile.inからMakefileを生成します。 Makefileを生成する際には、configureは単純な 変数置換を行います。これは、Makefile.in中に登場する @variable@をconfigureが求めた変数値で 置き換えることによって行われます。このようにして出力ファイルで 置換される変数のことをoutput variables(出力変数)と呼びます。 通常、出力変数はconfigureが設定するshell変数です。 configureにある変数値で置換を行わせる場合、変数名を 引数にしてマクロAC_SUBSTを呼び出す必要があります。 AC_SUBSTの呼び出されていない変数については、 @variable@はそのまま出力されます。 AC_SUBSTを使って出力変数を決める方法については See Setting Output Variablesを参照してください。

configureスクリプトを用いるソフトウェアパッケージは、 MakefileではなくてMakefile.inと一緒に配布される 必要があります; こうすれば、ユーザはコンパイルの前に必ず configureスクリプトを実行して、各々のシステムにあわせた 設定を行うことになります。

Makefileに何かを書くことに関するより多くの情報のために See Makefile Conventions, を参照してください。

• Preset Output Variables: Output variables that are always set.
• Build Directories: Supporting multiple concurrent compiles.
• Automatic Remaking: Makefile rules for configuring.

Preset Output Variables

Autoconfマクロでいくつかの出力変数が前もって設定されています。 Autoconfマクロの一部では、追加の出力変数を設定します。これについては 各マクロの説明のところで述べられています。 出力変数の完全なリストをみるにはSee Output Variable Indexを 参照してください。前もって設定される出力変数の意味を以下に示します。 dirで終る出力変数については、 See Directory Variables, を参照してください。

bindir

Variable

ユーザが実行する実行ファイルを格納するディレクトリです。

configure_input

Variable

「このファイルはconfigureによって 自動生成されました」というコメントと、 入力ファイル名を含んだコメント文字列です。 AC_OUTPUTは、生成するMakefileの 先頭に、この文字列を含むコメント行を 付け加えます。他のファイルについては、 この変数を各入力ファイル先頭のコメント 領域の中で参照しましょう。たとえば、 shellスクリプトである入力ファイルの先頭は 以下のようになります: #! /bin/sh # @configure_input@ また、この行を置いておくことで、ファイルを 編集するひとにconfigureを使って 処理しないといけない、ということを 思い出させることができます。

datadir

Variable

読み込み専用のアーキテクチャ非依存の データファイルを置くディレクトリ名です。

exec_prefix

Variable

アーキテクチャ依存のファイル名のプレフィックスです。

includedir

Variable

Cヘッダファイルをインストールする先のディレクトリ名です。

infodir

Variable

infoフォーマットのドキュメントをインストールする 先のディレクトリ名です。

libdir

Variable

ライブラリファイルをインストールする先の ディレクトリ名です。

libexecdir

Variable

(ユーザからではなく)他の実行ファイルから呼び出される 実行ファイルをインストールする先のディレクトリ名です。

localstatedir

Variable

各マシンごとの、変更可能なデータを格納するための ディレクトリ名です(訳註: XXX)。

mandir

Variable

manフォーマットのドキュメントをインストールする先の トップディレクトリ名です。

oldincludedir

Variable

gcc以外のコンパイラ向けのCヘッダファイルを インストールする先のディレクトリ名です。

prefix

Variable

アーキテクチャ非依存のファイルをインストールする際の ファイル名のプレフィックスです。

sbindir

Variable

システム管理者によって実行される実行ファイルを インストールする先のディレクトリです。

sharedstatedir

Variable

アーキテクチャ非依存の変更可能なデータを インストールする先のディレクトリ名です。

srcdir

Variable

Makefileの処理すべきソースコードの入っている ディレクトリ名です。

sysconfdir

Variable

読み込み専用のマシン単位のデータファイルを インストールする先のディレクトリ名です。

top_srcdir

Variable

パッケージのトップディレクトリです。トップディレクトリでは、 srcdirとおなじです。

CFLAGS

Variable

Cコンパイラのデバッグ/最適化のための オプションです。configureが 実行された環境で指定されていなかった場合、 AC_PROG_CCを呼び出したときの デフォルト値(または、呼び出さなかったら空)が 設定されます。configureはこの変数の 値を使って、Cコンパイラの機能チェックのための コンパイルを行います。

CPPFLAGS

Variable

CプリプロセッサとCコンパイラのための、 ヘッダファイル検索対象ディレクトリ (-Idir)と、その他の もろもろのオプションです。 もしconfigureが実行された 環境でこの変数が指定されなかった場合、 デフォルト値は空になります。 configureはこの変数の 値を使って、Cコンパイラの機能チェック のためのコンパイル、または プリプロセスを行います。

CXXFLAGS

Variable

C++コンパイラのデバッグ/最適化のための オプションです。configureが 実行された環境で指定されていなかった場合、 AC_PROG_CXXを呼び出したときの デフォルト値(または、呼び出さなかったら空)が 設定されます。configureはこの変数の 値を使って、C++コンパイラの機能チェックのための コンパイルを行います。

FFLAGS

Variable

Fortran 77コンパイラのデバッグや最適化オプションです。もし configureを実行するとき環境変数に設定されていなければ AC_PROG_F77を呼ぶときにデフォルト値が設定されます。(または、 AC_PROG_F77を呼ばなければ空になります) configureはFortran 77 の特徴をテストするプログラムをコンパイルするときにこの変数を使用しま す。

DEFS

Variable

Cコンパイラに渡す-Dオプションです。 AC_CONFIG_HEADERマクロが呼び出された 場合、configureは@DEFS@を -D群でなく、-DHAVE_CONFIG_Hで 置き換えます(see Configuration Headers 参照)。この変数はconfigureがテストを 行っている間は定義されません。出力ファイルを 生成するときにだけ定義されます。 既に行われてたテストの結果を参照する 場合には、See Setting Output Variablesを 参照してください。

LDFLAGS

Variable

リンカのためのstrip(-s)のためや 他のもろもろのためのオプションです。 configureが実行された環境で 指定されていなかった場合、 デフォルト値の空文字列が 設定されます。 configureはこの変数の値を 使って、Cコンパイラの機能チェックの 際のリンクを行います。

LIBS

Variable

リンカに渡す-lオプションと -Lです。

Build Directories

ソフトウェアパッケージを展開した単一のソースコードツリー上で、 同時に複数のアーキテクチャのためのコンパイルを行うことができます。 オブジェクトファイルは各アーキテクチャ別のディレクトリに格納されます。

このためには、makeはソースコードをみつけるために make変数VPATHを使用します。GNU makeと 最近のmakeのほとんどはこの機能をサポートしています。 古いmakeはVPATHをサポートしていません; 古いmakeを使う場合、ソースコードとオブジェクトファイルは 同じディレクトリに置かれていなければなりません。

VPATHをサポートするために、各Makefile.inには 以下ような行が含まれている必要があります:

srcdir = @srcdir@
VPATH = @srcdir@

VPATHを他の変数の値を使って設定しないでください(たとえば VPATH = $(srcdir)のように)。一部のmakeはVPATHの 値を設定する場合に変数置換を行います。

configureはMakefileを生成する際に、 srcdirを正しい値に設定し置換します。

make変数$<(VPATHを使ってみつけたソースディレクトリ中の ファイルのパス名)は、暗黙的ルールの中以外では使わないでください (暗黙的ルールとは、例えば.cファイルから.oファイルを 生成するための手順を定義する.c.oのルールのことです)。 一部のmakeは明示的ルール(訳中: 暗黙的ルールでないルール)の中では、 $<定義しません; $<は空になります。

そのかわりに、Makefileに記述するコマンドラインはソースファイルを $(srcdir)/で始めるようにしてください。例えば:

time.info: time.texinfo
        $(MAKEINFO) $(srcdir)/time.texinfo

Automatic Remaking

以下に示すようなルールをトップレベルのMakefile.inに含めると、 設定ファイルを変更したら自動的に設定情報を更新させることができます。 この例題にはaclocal.m4やconfiguration header fileのような、 使っても使わなくてもいいファイルが全て含まれています。 Makefile.inにルールを追加するときには、パッケージ中で 実際使わないものは省略してください。

${srcdir}/プレフィックスはVPATHの制限を回避するために 記述されています。

config.h.inとconfig.hの内容に変化がない場合、 これらのファイルのタイムスタンプは変わりません。 stamp-で始まる名前のファイルは、このせいで用いられています。 このようにすることで、余計な再設定を防ぐことができます。 この手法を使う場合、makeがconfig.h.inが更新済みだと 思うように、stamp-h.inをパッケージの配布に含める必要があります。 古いBSD系のシステムでは、touchや他のファイルで空ファイルが 作成される場合、タイムスタンプが変わりません。 このため、逃げ道としてechoを使っています。

${srcdir}/configure: configure.in aclocal.m4
        cd ${srcdir} && autoconf

# autoheader might not change config.h.in, so touch a stamp file.
${srcdir}/config.h.in: stamp-h.in
${srcdir}/stamp-h.in: configure.in aclocal.m4 acconfig.h \
    config.h.top config.h.bot
        cd ${srcdir} && autoheader
        echo timestamp > ${srcdir}/stamp-h.in

config.h: stamp-h
stamp-h: config.h.in config.status
        ./config.status

Makefile: Makefile.in config.status
        ./config.status

config.status: configure
        ./config.status --recheck

さらに、echo timestamp > stamp-hをAC_OUTPUTの 引数extra-cmdsに指定する必要があります。 config.statusを実行したときに、config.hが更新されたという ことがわかるようにするためです。AC_OUTPUTの詳細については See Outputを参照。

設定ファイルにまつわる依存関係については、See Invoking config.statusを 参照。

Configuration Header Files

パッケージの移植性テストで、Cプリプロセッサシンボルをいくつか以上 使う場合、コンパイラを起動するときのコマンドラインは、-Dオプションを 渡さなければならないので非常に長くなります。 この手法にはふたつの問題があります。まずmakeの出力を眺めて間違いを みつけるのが難しくなります。もっと深刻なのは、一部のOSのコマンドライン 長の制限を越えてしまう可能性がある、ということです。 -Dオプションを使うかわりに、configureスクリプトは #defineディレクティブを含んだCヘッダファイルを生成することができます。 AC_CONFIG_HEADERマクロでこのような出力ファイルを選択します。 このマクロはAC_INITの直後に呼び出す必要があります。

パッケージ中のソースコードでは、#includeディレクティブを使って、 configuration header fileを他のどのヘッダファイルよりも前に 読み込む必要があります。 一番最初に読み込むのは、定義の一貫性を保つためです(例えば、constを 再定義するヘッダを先に読み込んだりしたら困ります)。 #include "config.h"でなしに、#include <config.h>を使い、 Cコンパイラに-I.オプションを渡しましょう (あるいは-I..などと、config.hのあるディレクトリを 指定しましょう)。このようにすることで、ソースファイルのあるディレクトリに config.hがある状態でも、他のビルドディレクトリを作成して そちらのconfig.hを使ってパッケージをコンパイルすることができます (訳註: 結構意訳)。

AC_CONFIG_HEADER (header-to-create ...)

Macro

AC_OUTPUTにCプリプロセッサ向けの #defineディレクティブ入りの ファイルを作成させ、@DEFS@を (shell変数DEFSの値でなく) -DHAVE_CONFIG_Hに置換させます。 出力ファイル名はheader-to-createに、 スペースで区切って指定します。 通常、header-to-createに使う ファイル名はconfig.hです。 もしheader-to-createに指定された ファイルが既に存在していて、AC_OUTPUTが 出力しようとしている内容と同じ内容だったら、 ファイルは更新されずそのままになります。 このようにすることで、パッケージの設定の 一部を変更したとき、header-to-createに 指定されたヘッダファイルに依存している ファイルを余計に再コンパイルしなくて済みます。 通常、入力ファイルは header-to-create.inという名前です; が、もし名前を変えたい場合には header-to-createにコロンで区切った 名前の列を繋げることで変えられます。 たとえば: AC_CONFIG_HEADER(defines.h:defines.hin) AC_CONFIG_HEADER(defines.h:defs.pre:defines.h.in:defs.post) こうすることで、ファイル名をMS-DOSでも使える フォーマットにしたり、ファイルの前後に メッセージ(訳註: boilerplate)をつけたり することができます。

• Header Templates: Input for the configuration headers.
• Invoking autoheader: How to create configuration templates.

Configuration Header Templates

配布パッケージには、ヘッダファイルのテンプレートを含める必要があります。 テンプレートは出力がこうあってほしいと思うとおりに書き、 コメントと、デフォルト値を含めた#defineディレクティブを 書いておく必要があります。 例えば、configure.inが以下のマクロ呼び出しを含んでいる場合:

AC_CONFIG_HEADER(conf.h)
AC_CHECK_HEADERS(unistd.h)

以下のような行がconf.h.inに含まれている必要があります。 unistd.hがあるシステムでは、configureは #defineの行の0を1に変えて出力します。ないシステムでは、 そのまま出力します。

/* Define as 1 if you have unistd.h.  */
#define HAVE_UNISTD_H 0

あなたのプログラムが#ifでなく#ifdefで 設定オプションを調べている場合、入力ファイルにデフォルト値を設定する #defineの行を書くかわりに、#undefの行を書くことができます。 unistd.hがあるシステムでは、configureは 2行目を#define HAVE_UNISTD_H 1と書き換えます。 そうでないシステムでは、2行目をコメントアウトして出力します (コメントアウトするのは、このシンボルがシステムで既に使われている かもしれないからです)。

/* Define if you have unistd.h.  */
#undef HAVE_UNISTD_H

Using autoheader to Create config.h.in

autoheaderプログラムは、configureが使う Cの#defineディレクティブ入りのファイルを生成してくれます。 configure.inがAC_CONFIG_HEADER(file)を 呼び出している場合、autoheaderはfile.inを 生成します。複数のファイルが指定されていたら、最初のファイル名を使います。 さもなくば、autoheaderはconfig.h.inを生成します。

autoheaderにコマンドライン引数を渡した場合、 入力としてconfigure.inのかわりに指定されたファイルが使われ、 結果は(config.h.inでなく)標準出力に出力されます。 autoheaderに-をコマンドライン引数として渡すと、 (configure.inのかわりに)標準入力が読み込まれ、 結果は標準出力に出力されます。

autoheaderはconfigure.inを調べ、どんなCプリプロセッサシンボルが 定義される可能性があるか推測します。そして、 acconfig.hというファイルからコメントと#defineまたは #undefの行をコピーします。 上記のacconfig.hはAutoconfと一緒に配布され、所定の場所にインストール されているものです。 カレントディレクトリにもacconfig.hがある場合、こちらも使われます。 AC_DEFINEマクロで標準以外のシンボルを定義している場合、 それらのシンボルのぶんのエントリをカレントディレクトリのacconfig.hに 造っておく必要があります。 AC_CHECK_HEADERS、AC_CHECK_FUNCS、AC_CHECK_SIZEOF、 またはAC_CHECK_LIBで定義されるシンボルについては、 (acconfig.hから定義をコピーするのではなく) autoheaderがコメントと#undefの行を自動生成します。 なぜなら、これらのマクロで使われる可能性のあるシンボルは事実上無限に あるからです。

autoheaderの生成したファイルは、主に#defineまたは #undefと、付随するコメントからなります。 ./acconfig.hに@TOP@という文字列があった場合、 autoheaderは@TOP@を含む行以前の行を 出力の先頭にコピーします。 同様に、./acconfig.hに@BOTTOM@という文字列があった場合、 autoheaderは@BOTTOM@を含む行以降の行を 出力の末尾にコピーします。 どちらの文字列もなくても構いません。

file.top(通常config.h.topになります)や file.botという名前のファイルをカレントディレクトリに 作っておくと、同様の効果が得られます。 もしファイルがあった場合、autoheaderはファイルの内容を 出力の先頭(または末尾)にコピーします。 これらのファイルを使うのはおすすめしません。 なぜなら、これらのファイル名はMS-DOSファイルシステムに格納できないからです; また、2つのファイルを置くことでディレクトリがごちゃごちゃします。 でも利点もあります。 他のディレクトリにあるacconfig.hを読み込むために autoheaderの--localdir=dirオプションを使う場合には、 これら2つのファイルを使うと全ての出力ファイルに別々のメッセージ (訳註: boilerplate)をつけることができます。

autoheaderは以下のオプションを受け付けます:

--help

-h

コマンドラインオプションの説明を出力して終了します。

--localdir=dir

-l dir

aclocal.m4やacconfig.hを 探すとき、カレントディレクトリでなしに ディレクトリdirを探しにいきます。 autoheaderを呼び出す場合には、 file.topとfile.botに ついては挙動は変わりません。

--macrodir=dir

-m dir

デフォルトのディレクトリでなく、ディレクトリ dirにあるacconfig.hを参照します。 環境変数AC_MACRODIRを設定しても同じ効果が 得られます。コマンドラインオプションは環境変数の 設定より優先されます。

--version

Autoconfのバージョン番号を出力して終了します。

Configuring Other Packages in Subdirectories

ほとんどの場合、サブディレクトリにMakefileを作るには AC_OUTPUTを使えば十分です。 しかし、複数の独立したパッケージを制御するconfigure スクリプトを作る場合には、AC_CONFIG_SUBDIRSを使うことで サブディレクトリにあるconfigureスクリプトを呼び出すことができます。

AC_CONFIG_SUBDIRS (dir ...)

Macro

AC_OUTPUTマクロに、 dirに指定されたディレクトリ にあるconfigureを実行させます。 ディレクトリが複数の場合はdirに ディレクトリをスペースで区切って並べます。 ディレクトリdirがみつからない場合、 エラーにはなりません。これは、 configure大きなソースコード ツリーのうちの実在する一部分だけを 設定できるようにするためです。 dirにconfigure.inがあって configureがない場合、Cygnus ディレクトリAC_CONFIG_AUXDIRにある Cygnus configureスクリプトが 使われます。 サブディレクトリにあるconfigure スクリプトには、現在実行中の configureスクリプトと、 基本的には同じコマンドライン引数が 渡されます。 コマンドライン引数は必要な場合には わずかに変更されます(例えば、 キャッシュファイルやソースファイルの あるディレクトリへの相対パスの調整など)。 このマクロは出力変数subdirsに、 サブディレクトリのリスト(dir ...) を設定します。Makefileルールでは この変数を使って、どのサブディレクトリを 再帰的にmakeすればいいのか決める ことができます。このマクロは複数回 呼び出しても構いません。

Default Prefix

デフォルトでは、configureはインストールのためのファイル名の ディレクトリプレフィクスを/usr/localに設定します。configureの ユーザは、--prefixと--exec-prefixオプションを使って、 他のディレクトリプレフィクスを選択することができます。 デフォルトの設定を変更するにはふたつの方法があります: configure生成時と、configureの実行時です。

一部のソフトウェアパッケージでは、デフォルトで/usr/local以外のところに インストールしたい場合があるでしょう。このためには、 AC_PREFIX_DEFAULTマクロを使ってください。

AC_PREFIX_DEFAULT (prefix)

Macro

デフォルトのインストールディレクトリ プレフィクスを、/usr/local でなくprefixにします。

configureスクリプトが、既にインストールされている 関係あるプログラムのインストール位置から、 インストールディレクトリプレフィクスを推測してくれると 便利なこともあるでしょう。このためには、AC_PREFIX_PROGRAMを 呼び出しましょう。

AC_PREFIX_PROGRAM (program)

Macro

ユーザがインストールディレクトリ プレフィクスを(--prefixオプションで) 指定しなかった場合、値をprogramの 位置から推測します。programは shellと同様、PATHをたぐって 探されます。もしprogramが PATHに書かれたディレクトリの どこかに存在した場合、ディレクトリ プレフィクスをprogramのある ディレクトリの親ディレクトリに 設定します; もしなかったら、 Makefile.inに指定された プレフィクスをそのままにします。 例えば、programがgccで、 PATHを探した結果 /usr/local/gnu/bin/gccが 見つかった場合、プレフィクスは /usr/local/gnuになります。

Version Numbers in configure

以下のマクロはconfigureスクリプトのバージョン番号を管理します。 このマクロは使っても使わなくても構いません。

AC_PREREQ (version)

Macro

Autoconfの十分最近のバージョンが 使われているか確かめます。 configureを生成するのに 使われているAutoconfがversion 以前のものだった場合、エラーメッセージを 標準エラー出力に出力し、configureを 生成しません。例えば: AC_PREREQ(1.8) このマクロは、configure.inが、 Autoconfのバージョンアップで変化した 自明でないふるまいに依存している場合に 役立ちます。もし最近定義されたマクロが 必要なだけの場合、AC_PREREQマクロは あまり使いでがありません。なぜなら、 autoconfはAutoconfの ユーザに、マクロがないというエラーを 出力しているはずだからです。 同様のことは、cofigure.inを AC_PREREQが追加される以前の Autoconfに通したときに起こります。

AC_REVISION (revision-info)

Macro

revision-infoに指定したRCS リビジョンスタンプ(訳註: $Id $ とかのこと)を、$マークや ダブルクォートを取り除いてから configureスクリプトに埋め込みます。 このマクロを使ってconfigure.inの リビジョンスタンプconfigureスクリプトに 取り込むと、RCS/CVSによって configure内のリビジョンスタンプを 書き換えられずに済みます。 このようにすれば、configure スクリプトがどのリビジョンの configure.inから生成されたかを 簡単に知ることができます。 このマクロをAC_INIT以前に 使うようにすると、リビジョン番号が configure.inとconfigureの どちらでも先頭部分に入るので、 具合がよいです。 このように使われることを想定して、 AC_REVISIONの出力は #! /bin/shという行ではじまります。 これは通常のconfigureの 始まり方と同じです。 例えば、configure.in中の以下のような行は: AC_REVISION($Revision: 1.30 $)dnl configureに以下のような出力を生成します: #! /bin/sh # From configure.in Revision: 1.30

Existing Tests

以下のマクロは、パッケージが必要な、あるいは使いたい特定のOSの機能を 調べます。以下のマクロに定義されていない機能の有無をチェックしたい場合、 基本テストマクロ(primitive test macro)に適切な引数を渡してチェックを 実現することになります(see Writing Tests参照)。

以下のテストは、どの機能をチェックしているか、なにがわかったかを 知らせるメッセージを出力します。チェック結果はconfigureを 再度実行したときのためにキャッシュされます(see Caching Results参照)。

マクロには出力変数を設定するものがあります。出力変数の値を 参照するやりかたについてはSee Makefile Substitutionsを参照してください。 以下で、「nameを定義します」という文は、 「Cプリプロセッサシンボルnameを1に定義します」という意味です。 定義された値をプログラム中で参照するやりかたについてはSee Defining Symbols を参照してください。

• Alternative Programs: Selecting between alternative programs.
• Libraries: Library archives that might be missing.
• Library Functions: C library functions that might be missing.
• Header Files: Header files that might be missing.
• Structures: Structures or members that might be missing.
• Typedefs: typedefs that might be missing.
• C Compiler Characteristics:
• Fortran 77 Compiler Characteristics:
• System Services: Operating system services.
• UNIX Variants: Special kludges for specific UNIX variants.

Alternative Programs

以下のマクロは特定のプログラムの有無、またはふるまいをチェックします。 マクロは、いくつかの候補となるプログラムからどれかひとつを選んだり、 選んだものをどう利用するかを定めるために使われます。 パッケージで使うプログラム専用のマクロが定義されておらず、 そのプログラムに関する特殊なチェックが必要ない場合、 汎用のマクロのうちいずれかを利用することができます。

• Particular Programs: Special handling to find certain programs.
• Generic Programs: How to find other programs.

Particular Program Checks

以下のマクロは特定のプログラムをチェックします-- プログラムが存在するかどうか、およびいくつかのプログラムについては プログラム特有の機能をチェックします。

AC_DECL_YYTEXT

Macro

yytextの型がchar []でなく char *だった場合、 YYTEXT_POINTERを定義します。 また、lexの出力ファイル名を 出力変数LEX_OUTPUT_ROOTに 定義します。通常はlex.yyですが 他の値のこともあります。これらの結果は lexとflexのどちらが 利用されているかによって変わります。

AC_PROG_AWK

Macro

mawk、gawk、nawk、 awkがあるかどうかをこの順序で 調べ、出力変数AWKの値を 最初にみつけたプログラムの 名前に設定します。mawkを最初に 調べるのは、これが一番高速動作する 実装だと言われているからです。

AC_PROG_CC

Macro

利用するCコンパイラを決定します。 環境変数CCが設定されて いなかったら、gccがあるか どうか調べ、なければccを 使います。出力変数CCを みつけたコンパイラの名前に設定します。 このマクロは、GNU Cコンパイラを使う場合 shell変数GCCをyesに、 そうでない場合空に設定します。 もし出力変数CFLAGSがまだ 設定されていなかったら、 GNU Cコンパイラの場合には -g -O2に設定します (GCCが-gを受け付けない場合 -O2に、他のコンパイラの場合 -gに設定します)。 現在利用することになっている Cコンパイラが、configureが 実行されているシステム以外のための バイナリを生成する場合、 shell変数cross_compilingを yesに設定します。 そうでない場合noに設定します。 言い替えれば、このテストは build対象のシステムが ホストシステムタイプ(訳註: コンパイルを行うシステムのタイプ)と 異なるかどうかを調べます (「ターゲットシステムタイプ」は このマクロとは無関係です)。 クロスコンパイルのサポートに ついてはSee Manual Configurationを 参照してください。

AC_PROG_CC_C_O

Macro

Cコンパイラがコマンドラインオプション -cと-oを 同時に受け付けない場合、 NO_MINUS_C_MINUS_Oを定義します。

AC_PROG_CPP

Macro

出力変数CPPに、Cプリプロセッサを 実行するためのコマンド名を定義します。 $CC -Eが動かない場合、 /lib/cppが使われます。 CPPを.cファイル以外に 用いるのは移植性がありません。 移植性のために、CPPに通すのは 拡張子が.cのファイルだけにしましょう。 現在選択されている言語がCの場合 (see Language Choice参照)、 一部のテストマクロは出力変数CPPの 値を間接的に利用しています。 「間接的に」というのは、テストマクロ内部でマクロ AC_TRY_CPP、AC_CHECK_HEADER、 AC_EGREP_HEADER、AC_EGREP_CPPを 呼び出しているからです。

AC_PROG_CXX

Macro

利用するC++コンパイラを判別します。 環境変数CXXまたはCCCが 定義されていないか(CXXを先に) 調べます; もし定義されていたら、定義されている値を 出力変数CXXにセットします。 さもなくば、C++コンパイラらしい名前の プログラムを探します (c++, g++, gcc, CC, cxx, それからcc++)。 もし以上のチェックが全て失敗したら、 最後の手段としてCXXをgccにセットします。 GNU C++コンパイラを利用する場合、 shell変数GXXをyesに、 さもなくば空にセットします。 出力変数CXXFLAGSがまだ定義されて いない場合、CXXFLAGSを定義します。 GNU C++コンパイラを 利用するなら-g -O2(GNU C++が -gを受け付けない場合-O2)に、 他のコンパイラの場合は-gになります。 現在利用することになっている C++コンパイラが、configureが 実行されているシステム以外のための バイナリを生成する場合、 shell変数cross_compilingを yesに設定します。 そうでない場合noに設定します。 言い替えれば、このテストは build対象のシステムが ホストシステムタイプ(訳註: コンパイルを行うシステムのタイプ)と 異なるかどうかを調べます (「ターゲットシステムタイプ」は このマクロとは無関係です)。 クロスコンパイルのサポートに ついてはSee Manual Configurationを 参照してください。

AC_PROG_CXXCPP

Macro

出力変数CXXCPPに、C++プリプロセッサを 実行するためのコマンド名を定義します。 $CXX -Eが動かない場合、 /lib/cppが使われます。 CXXCPPを.c、.C または.cc以外のファイルに 用いるのは移植性がありません。 移植性のために、CPPに通すのは 上記に挙げた拡張子をもつファイルだけにしましょう。 現在選択されている言語がC++の場合 (see Language Choice参照)、 一部のテストマクロは出力変数CXXCPPの 値を間接的に利用しています。 「間接的に」というのは、テストマクロ内部でマクロ AC_TRY_CPP、AC_CHECK_HEADER、 AC_EGREP_HEADER、AC_EGREP_CPPを 呼び出しているからです。

AC_PROG_F77

Macro

利用するFortran 77コンパイラを決定します。環境変数F77が設定されて いなかったら、g77、f77 そして f2cを この順番で調べます。出力変数F77をみつけたコンパイラの名前に設定し ます。 g77(GNU Fortran 77コンパイラ)を使う場合AC_PROG_F77はshell 変数G77をyesに、そうでない場合空に設定します。もし出力変数 FFLAGSがその環境でまだ設定されていなかったら、g77の場合に は-g -02を(g77が-gを受け付けない場合-O2に設 定します)、他のコンパイラの場合-gにFFLAGSを設定します

AC_PROG_F77_C_O

Macro

Fortran 77コンパイラがオプション-cと-oを同時に受け付けるか どうかテストします。もし受け付けなければF77_NO_MINUS_C_MINUS_O を 定義します。

AC_PROG_GCC_TRADITIONAL

Macro

GNU Cコンパイラを使っていて、 -traditionalフラグを指定しないと ioctlがうまく動かない場合、 出力変数CCに-traditionalを 付け加えます。 通常、これはGNU Cコンパイラ用に修正された ヘッダファイルがインストールされていない 古いシステムで起こります。 GNU Cコンパイラの最近のバージョンでは、 インストール時にヘッダファイルを修正するので、 この問題は起きなくなってきました。

AC_PROG_INSTALL

Macro

現在のPATH上にBSD互換の installプログラムがあった場合、 出力変数INSTALLをその名前にセットします。 さもなくば、dir/instal-sh -cを セットします。 後者の場合、AC_CONFIG_AUX_DIRに 指定されたディレクトリ(またはデフォルトの ディレクトリ)を使ってdirを決定します (see Output)。 さらに、INSTALL_PROGRAMとINSTALL_SCRIPTを${INSTALL}に、 INSTALL_DATAを${INSTALL} -m 644にセットします。 このマクロは、うまく動作しない installプログラムを無視します。 プログラムを探す際には、速度のためにスクリプトよりは Cで書かれたプログラムの方を優先します。 install-sh以外に、install.shを 使うこともできますが、install.shという ファイル名はobsoleteなので使わない方がいいでしょう(訳註: 意訳)。 これは、 一部のmakeが、Makefileがないときに install.shからinstallを生成する ルールをもっているためです。 パッケージに含める(訳註: 意訳) install-shとしては、 Autoconfと一緒に配布されているinstall-shを 利用することができます。 AC_PROG_INSTALLを利用した場合、 install-shまたはinstall.shを 配布に含める必要があります。 含めなかった場合、configureは ファイルがみつからなかった旨 エラーメッセージを出力します。 エラーメッセージは正しく動作する installがある場合にも出力されます。 このチェックは、install-shを パッケージに含め忘れないための安全策です。 含め忘れた場合、あなたのパッケージを BSD互換のinstallプログラムのない システムでインストールできなくなってしまいます。 標準的なinstallプログラムにない機能が 必要で独自のインストールプログラムを利用したい 場合には、AC_PROG_INSTALLを利用する 必要はありません; 御自分のインストールプログラムへの パス名をMakefile.inに単に含めればいいのです。

AC_PROG_LEX

Macro

flexがあったら、出力変数LEXを flexに、(もしlibfl.aが 標準的な場所にあったら)LEXLIBを -lflに設定します。 もしflexがなかったら、 LEXをlexに、 LEXLIBを-llに設定します。

AC_PROG_LN_S

Macro

ln -sが現在のファイルシステムで うまく使えたら(すなわち、OSとファイルシステムが シンボリックリンクをサポートしていたら)、 出力変数LN_Sをln -sに設定します。 動かなかったら、lnに設定します。 カレントディレクトリ以外のパス名をリンク先として 指定した場合、lnとln -sでは 意味が異なってきます。 $(LN_S)を使って安全にリンクを作成するためには、 makefile中でどちらが使われているか調べて動作を変えるか、 lnコマンドをリンクが置かれるディレクトリで 呼び出すかのいずれかを行わねばなりません。 言い替えれば、以下はうまく動きません: $(LN_S) foo /x/bar ので、かわりにこうしましょう: (cd /x && $(LN_S) foo bar)

AC_PROG_RANLIB

Macro

もしranlibがみつかったら、出力変数 RANLIBをranlibに設定します。 さもなくば、:(なにもしない)に設定します。

AC_PROG_YACC

Macro

もしbisonがみつかったら、出力変数 YACCをbison -yに設定します。 かわりにbyaccがみつかったら、出力変数 YACCをbyaccに設定します。 さもなくば、yaccに設定します。

Generic Program and File Checks

以下のマクロは、プログラムをみつけるための専用マクロが特に 定義されていないプログラムをみつけるために使われます。 プログラムの存在だけでなくプログラムの挙動を調べたい場合、 自分でテストスクリプトを記述する必要があります(see Writing Tests)。 デフォルトでは、マクロは環境変数PATHを使います。 ユーザのPATHにないようなプログラムをチェックする場合、 以下のように自分でサーチパスを変更してマクロに渡すことができます:

AC_PATH_PROG(INETD, inetd, /usr/libexec/inetd,
  $PATH:/usr/libexec:/usr/sbin:/usr/etc:etc)

AC_CHECK_FILE (file [, action-if-found [, action-if-not-found]])

Macro

ファイルfileがシステムに存在するかどうかを検査します。 もしみつかればaction-if-foundが実行され、みつからなければ (もし与えられていれば)action-if-not-foundが実行されます。

AC_CHECK_FILES (files[, action-if-found [, action-if-not-found]])

Macro

AC_CHECK_FILEをfilesに列挙したそれぞれのファイルごとに一度 ずつ実行します。さらに見つけたファイルそれぞれに対して HAVE_fileを1に定義します。

AC_CHECK_PROG (variable, prog-to-check-for, value-if-found [, value-if-not-found [, path, [ reject ]]])

Macro

プログラムprog-to-check-forがPATH中に あるかどうかを調べます。もし発見された場合variableを value-if-foundに設定します。発見されなかった場合 (value-if-not-foundが指定されていた場合は) value-if-not-foundに設定します。 このマクロは、reject (絶対パスのファイル名)を サーチパス上で発見してもそれは無視します。 この場合、variableはパス上でみつかった prog-to-check-forで、rejectではない ファイルの絶対パス名になります。 variableが既に設定されていた場合、なにもしません。 variableのために、AC_SUBSTを呼び出します。

AC_CHECK_PROGS (variable, progs-to-check-for [, value-if-not-found [, path]])

Macro

progs-to-check-forに指定された、 スペースで区切られたプログラム名たちがPATH上に あるかどうかを調べます。もしあった場合、 そのプログラム名をvariableに設定します。 さもなくば、次のプログラム名を探します。 もし、指定された全てのプログラムがなかった場合、 value-if-not-foundの値をvariableに設定します。 もしvalue-if-not-foundが指定されていなかったら、 variableの値は変更されません。 variableのために、AC_SUBSTを呼び出します。

AC_CHECK_TOOL (variable, prog-to-check-for [, value-if-not-found [, path]])

Macro

AC_CHECK_PROGと同様ですが、prog-to-check-forの 先頭にAC_CANONICAL_HOSTで判定されたホストタイプを つけたものを最初に探します(see Canonicalizing参照)。 例えば、ユーザがconfigure --host=i386-gnuを 実行し、その中で AC_CHECK_TOOL(RANLIB, ranlib, :) というマクロが使われていたなら、まずパス上の i386-gnu-ranlibが探され、もしあったなら i386-gnu-ranlibをRANLIBに設定します。 プログラムがなければRANLIBは:にされます。

AC_PATH_PROG (variable, prog-to-check-for [, value-if-not-found [, path]])

Macro

AC_CHECK_PROGと同様ですが、 プログラムが発見された場合variableを prog-to-check-forの絶対パスに設定します。

AC_PATH_PROGS (variable, progs-to-check-for [, value-if-not-found [, path]])

Macro

AC_CHECK_PROGSと同様ですが、 progs-to-check-forの中のいずれかが 見付かったら、プログラムの絶対パスを variableに設定します。

Library Files

以下のマクロは指定されたC、C++、Fortran 77ライブラリファイル(および中身)が 存在するかどうかを調べます。

AC_CHECK_LIB (library, function [, action-if-found [, action-if-not-found [, other-libraries]]])

Macro

現在選択されている言語によって(see Language Choice)、 functionに指定されたC、C++、Fortran 77の関数が存在するか どうかを調べます。 チェックはテスト用のCプログラムとライブラリ libraryを一緒にリンクしてみて成功するかどうかで 行われます。 libraryはライブラリのベースネームです。 例えば、-lmpを調べる場合、mpを 引数libraryに指定することになります。 action-if-foundには、リンクが成功した場合に 呼び出されるshellコマンド列を指定します。 action-if-not-foundには、リンクが失敗したときに 呼び出されるshellコマンド列を指定します。 action-if-foundが 指定されなかった場合、デフォルトの動作になります。 デフォルトの動作はLIBに-llibraryを追加し、 HAVE_LIBlibraryを(全部大文字)定義するように なっています。 もしlibraryだけとリンクするのでは未解決のシンボルが 出てしまい、他のライブラリをリンクしないといけない場合には、 それらのライブラリ名をスペースで区切ってother-librariesに 指定してください: -lXt -lX11のように。 指定しなかった場合、マクロはlibraryが存在することを 検出できません。なぜなら、未解決シンボルのせいでリンクが 常に失敗するからです。

AC_HAVE_LIBRARY (library, [, action-if-found [, action-if-not-found [, other-libraries]]])

Macro

このマクロはAC_CHECK_LIBを、引数functionを mainにして呼び出すのと同じです。引数libraryは fooでも-lfooでも、あるいはlibfoo.a とでも指定できます。これらの全ての場合に、コンパイラには 引数-lfooが渡ります。 libraryにshell変数を渡すことはできません。 libraryは文字列リテラルである必要があります。 このマクロはobsoleteです。

AC_SEARCH_LIBS (function, search-libs [, action-if-found [, action-if-not-found [, other-libraries]]])

Macro

もしまだそのライブラリを利用するように設定されていなければfunction を定義したライブラリを探します。これはAC_TRY_LINK_FUNCを最初にラ イブラリなしで、それからsearch-libsに列挙されたライブラリをそれぞ れ指定して呼び出すのと同じです。 関数が見つかればaction-if-foundを実行します。そうでなければ action-if-not-foundを実行します。 もし、libraryのリンクがシンボル未解決という結果になり、追加のライ ブラリとともにリンクすることによってそれが解決するようならば、そのような ライブラリをother-libraries引数に空白区切りで-lXt -lX11のよ うに与えてください。そうでなければ、テストプログラムのリンクがいつもシン ボル未解決で失敗するので、このマクロはfunctionが存在することを発見 するのに失敗するでしょう。

AC_SEARCH_LIBS (function, search-libs[, action-if-found [, action-if-not-found]])

Macro

このマクロは、それぞれのライブラリをsearch-libsでリストアップした AC_TRY_LINK_FUNCの一回の呼び出しと同じです。特定のfunction が見つかった最初のライブラリに対し、-llibraryをLIBS に追加し、action-if-foundを実行します。それ以外の場合は action-if-not-foundを実行します。

Library Functions

以下のマクロは、Cのライブラリ関数があるかどうかを調べます。 もし、あるマクロをチェックする特別の関数が定義されておらず、 特殊なチェックが必要でない場合には、汎用の関数チェックマクロを 用いることができます。

• Particular Functions: Special handling to find certain functions.
• Generic Functions: How to find other functions.

Particular Function Checks

以下のマクロは、特定のCライブラリ関数をチェックします -- 関数が存在するかどうか、および特定の引数を与えられたときの 挙動がチェックされます。

AC_FUNC_ALLOCA

Macro

allocaの有無をチェックします。 このチェックでは、なるべくコンパイラ組み込みの allocaを探そうとします。 このために、alloca.hがあるかどうかおよび Cプリプロセッサマクロ__GNUC__と _AIXがあらかじめ定義されているかを調べます。 もしalloca.hがみつかったら、 HAVE_ALLOCA_Hが定義されます。 上記のチェックが失敗したら、標準Cライブラリに 関数があるかどうかを探します。 ここまでのチェックのいずれかが成功した場合、 HAVE_ALLOCAを定義します。 全てが失敗した場合、出力変数ALLOCAを alloca.oに定義し、C_ALLOCAを定義します (C_ALLOCAは、プログラムがGCのために 定期的にalloca(0)を呼び出すことが できるようにするため定義されます)。 ALLOCAはLIBOBJSとは独立に定義されます。 これは複数のプログラムをコンパイルするとき、 allocaを実際使うものが少なかった場合に いちいちalloca.oをコンパイルしなくて済むようにするためです (訳註: 超意訳。自信なし。原文は「 This variable is separate from LIBOBJS so multiple programs can share the value of ALLOCA without needing to create an actual library, in case only some of them use the code in LIBOBJS.」)。 このマクロはSystem V R3のlibPWや System V R4のlibucbに含まれる allocaを探すことはしません。 なぜなら、これらのライブラリには 場合によってはallocaが 含まれていなかったり、 含まれていてもallocaバグがあったり、 あるいは互換性に問題のあるalloca以外の 関数が含まれていたりするためです。 どうしてもこれらのライブラリに含まれる allocaを利用したい場合には、 (alloca.cをコンパイルするのではなく) arを使ってalloca.oを取り出してください。 allocaを利用するソースファイルには、 正しく定義を行うため先頭部分に以下のような コードが含まれている必要があります。 AIXの一部のバージョンにおいては、allocaの 宣言は(コメントやプリプロセッサディレクティブを 除いて)ファイルの一番先頭に現れる必要があります。 #pragmaディレクティブはANSI以前のCコンパイラでは 無視されることを期待して書かれています。 /* AIX requires this to be the first thing in the file. */ #ifndef __GNUC__ # if HAVE_ALLOCA_H # include <alloca.h> # else # ifdef _AIX #pragma alloca # else # ifndef alloca /* predefined by HP cc +Olibcalls */ char *alloca (); # endif # endif # endif #endif

AC_FUNC_CLOSEDIR_VOID

Macro

ライブラリ関数closedirが 意味のある値を返さない場合、CLOSEDIR_VOIDを 定義します。 定義されなかった場合には、 closedirを呼んだ場合 返り値を用いてエラーチェックを行うべきです。

AC_FUNC_FNMATCH

Macro

ライブラリ関数fnmatchが存在し、かつ動作するなら、 HAVE_FNMATCHを定義します (ちなみに、SunOS 5.4付属のものは動きません)。

AC_FUNC_GETLOADAVG

Macro

システムのロードアベレージを得る方法をチェックします。 現在のシステムでgetloadavgが利用できるなら、 HAVE_GETLOADAVGを定義し、 LIBSに必要なライブラリファイルを追加します。 もしgetloadavgが利用できないなら、 getloadavg.oを出力変数LIBOBJSに追加し、 必要ならいくつかのCプリプロセッサマクロや出力変数を定義します: SVR4、DGUX、UMAXまたは UMAX4_3のうちであてはまるものを定義します。 nlist.hがあった場合、NLIST_STRUCTを定義します。 struct nlistにメンバn_unがあった場合、 NLIST_NAME_UNIONを定義します。 getloadavg.cをコンパイルする際に LDAV_PRIVILEGEDが定義された場合、 getloadavgが正しく動作するには、 プログラムは(setuid bitをたてるなどして) root権限で動作するようにインストールされる必要があります。 この場合、GETLOADAVG_PRIVILEGEDが定義されます。 出力変数NEED_SETGIDが定義されます。 インストールする際にsetgid bitをたてる必要がある場合には 値はtrueに、さもなくば値はfalseになります。 NEED_SETGIDがtrueである場合には、 プログラムファイルの所属すべき gidがKMEM_GROUPに定義されます。

AC_FUNC_GETMNTENT

Macro

getmntentがライブラリファイル sun、seqおよびgenの いずれかに含まれているかどうか調べます (順に、Irix 4、PTX、Unixwareの場合の ライブラリファイルです)。 getmntentが存在した場合、 HAVE_GETMNTENTを定義します。

AC_FUNC_GETPGRP

Macro

getpgrpが引数をとらない場合 (つまりPOSIX.1準拠の場合)、 GETPGRP_VOIDを定義します。 定義されなかった場合、getpgrpはBSDでのように プロセスIDを引数にとります。 このマクロはgetpgrpがあるかどうかは 全く調べません; getpgrpがない場合に 対処するには、先にAC_CHECK_FUNCを使って getpgrpがあるかどうか調べてください。

AC_FUNC_MEMCMP

Macro

ライブラリ関数memcmpがないか、 または(SunOS 4.1.3のように)8bitデータに対して 使えない場合、memcmp.oを 出力変数LIBOBJSに追加します。

AC_FUNC_MMAP

Macro

mmapが存在して正常動作する場合、 HAVE_MMAPを定義します。 動作チェックは、既にマップされたメモリを 自プロセスの固定アドレスにマップする場合に関してのみ 行われます。

AC_FUNC_SELECT_ARGTYPES

Macro

関数selectの引数それぞれに渡される正しい型を決定し、 SELECT_TYPE_ARG1、SELECT_TYPE_ARG234、 SELECT_TYPE_ARG5それぞれにその型を定義します。 SELECT_TYPE_ARG1はintにデフォルト設定され、 SELECT_TYPE_ARG234はint *にデフォルト設定され、 SELECT_TYPE_ARG5はstruct timeval *にデフォルト設定されます。

AC_FUNC_SETPGRP

Macro

setpgrpが引数をとらない場合 (つまりPOSIX.1準拠の場合)、 SETPGRP_VOIDを定義します。 定義されなかった場合、setpgrpはBSDでのように プロセスIDを引数にとります。 このマクロはsetpgrpがあるかどうかは 全く調べません; setpgrpがない場合に 対処するには、先にAC_CHECK_FUNCを使って setpgrpがあるかどうか調べてください。

AC_FUNC_SETVBUF_REVERSED

Macro

setvbufの第2引数がバッファリングの形式で、 第3引数がバッファへのポインタの場合、 SETVBUF_REVERSEDを定義します。 SETVBUF_REVERSEDが定義されるのは、 release 3以前のSystem Vの場合です。

AC_FUNC_STRCOLL

Macro

strcollが存在して正常動作する場合、 HAVE_STRCOLLを定義します。 このマクロはstrcollがあるかどうかを AC_CHECK_FUNCより詳しく調べます。 一部のシステムでは、strcollの 定義が誤っているためこの関数を使うべきではないからです。

AC_FUNC_STRFTIME

Macro

strftimeがintlライブラリにあるかどうかを調べます (これはSCO UNIXのためです)。 もしあった場合、HAVE_STRFTIMEを定義します。

AC_FUNC_UTIME_NULL

Macro

utime(file, NULL)がfileの タイムスタンプを現在時刻に設定する場合、 HAVE_UTIME_NULLを定義します。

AC_FUNC_VFORK

Macro

vfork.hがあった場合、HAVE_VFORK_Hを定義します。 正常動作動作するvforkが発見されなかった場合、 vforkをforkに#defineします。 このマクロは、いくつかのシステムでのvforkの バグをチェックし、バグつきの場合にはvforkが みつからなかったかのように振舞います。 ただし、子プロセスでsignalを呼んでも 親プロセスのシグナルハンドラが変更されない場合には これはバグつきとはみなされません。 子プロセスでシグナルハンドラを変更することは めったにないからです。

AC_FUNC_VPRINTF

Macro

vprintfが存在する場合、 HAVE_VPRINTFを定義します。 ない場合に_doprntが存在したら、 HAVE_DOPRNTを定義します。 ちなみに、vprintfが存在したら、 vfprintfとvsprintfも 存在すると仮定して構いません。

AC_FUNC_WAIT3

Macro

wait3が存在し、呼び出し時に第3引数 (struct rusage *)の指し先の内容がきちんと 設定される場合、 HAVE_WAIT3を定義します。 ちなみに、HP-UXでは第3引数の差し先はきちんと設定されません。

Generic Function Checks

以下のマクロは、チェックのための特別のマクロがないライブラリ関数について 調べるために用意されています。 ライブラリ関数がデフォルトのCライブラリに入っていない 可能性がある場合には、AC_CHECK_LIBを用いて そのライブラリファイルがあるかどうか調べてください。 ライブラリ関数があるかどうかだけでなく、その振舞いも調べる 必要がある場合には、自前でテストを記述する必要があるでしょう (see Writing Tests)。

AC_CHECK_FUNC (function, [action-if-found [, action-if-not-found]])

Macro

Cの関数functionが存在する場合、shellコマンドaction-if-foundを 実行します。 ない場合にはaction-if-not-foundを実行します。 関数のあるなしによってシンボルを定義したいだけであれば、 AC_CHECK_FUNCSを使ったほうがいいでしょう。 このマクロはAC_LANG_CPLUSPLUSが呼ばれているいないに関わらず C linkageで関数を探します。 C++ではCよりもライブラリ関数がきちんと標準化されているので、 AC_CHECK_FUNCを使う機会は少なそうだからです (環境を調べる対象の言語を選ぶやりかたについては、 see Language Choiceを参照)。

AC_CHECK_FUNCS (function... [, action-if-found [, action-if-not-found]])

Macro

スペースで区切られた複数のfunctionのうち、 実際存在するものについてHAVE_function(全部大文字)を定義します。 action-if-foundには、 各々の関数がみつかったときに実行したいshellスクリプトを記述します。 action-if-foundをbreakにすると、 最初に関数が見つかったところでループを抜けることができます。 action-if-not-foundには、 各関数がみつからなかったときに実行されるshellスクリプトを記述します。

AC_REPLACE_FUNCS (function...)

Macro

このマクロは、 特定の関数functionが存在しない場合に LIBOBJSにfunction.oを追加します。 この動作は、 AC_CHECK_FUNCSで action-if-not-foundに 「出力変数LIBOBJSにfunction.oを追加する」 と記述した場合と似ています。 ライブラリの置き換え用の関数を定義するときには、 プロトタイプ宣言を#ifndef HAVE_functionで くくっておいた方がいいでしょう。 システムにfunctionがある場合、 システム定義のincludeファイルのどこかにプロトタイプ宣言があるはずです。 定義が矛盾するかもしれないから、システムにfunctionが あるときには再定義を避けるべきです。

Header Files

以下のマクロはCヘッダファイルがあるかないか調べます。 あなたのチェックしたいヘッダファイルについて 特定ヘッダファイル向けのマクロがなくて、 しかも特殊なことを調べる必要がなければ、 汎用のヘッダファイル検査マクロを使うとよいでしょう。

• Particular Headers: Special handling to find certain headers.
• Generic Headers: How to find other headers.

Particular Header Checks

以下のマクロは特定のシステムヘッダファイルを検査します。 ファイルがあるかどうか、それから必要なときには なにを定義しているかを検査します。

AC_DECL_SYS_SIGLIST

Macro

sys_siglistがsignal.hまたはunistd.hで定義されているなら、 SYS_SIGLIST_DECLAREDを定義します。

AC_DIR_HEADER

Macro

AC_HEADER_DIRENTとAC_FUNC_CLOSEDIR_VOIDを呼ぶのと似ていますが、 定義するCプリプロセッサマクロが違います。 AC_DIR_HEADERは どのヘッダファイルがみつかったのかを表すCプリプロセッサマクロを定義します。 AC_DIR_HEADER、およびこれにより定義されるCプリプロセッサマクロは obsoleteです。 定義されるCプリプロセッサマクロは以下のとおり: dirent.h DIRENT sys/ndir.h SYSNDIR sys/dir.h SYSDIR ndir.h NDIR さらに、関数closedirの返り値に意味がない場合には VOID_CLOSEDIRを定義します。

AC_HEADER_DIRENT

Macro

以下のヘッダファイルの有無を調べます。 そして、ヘッダファイルが存在しDIRを定義した最初のファイルについて 以下のCプリプロセッサマクロを定義します: dirent.h HAVE_DIRENT_H sys/ndir.h HAVE_SYS_NDIR_H sys/dir.h HAVE_SYS_DIR_H ndir.h HAVE_NDIR_H ソースコード中でディレクトリライブラリのための定義をするには、 以下のようにするといいでしょう: #if HAVE_DIRENT_H # include <dirent.h> # define NAMLEN(dirent) strlen((dirent)->d_name) #else # define dirent direct # define NAMLEN(dirent) (dirent)->d_namlen # if HAVE_SYS_NDIR_H # include <sys/ndir.h> # endif # if HAVE_SYS_DIR_H # include <sys/dir.h> # endif # if HAVE_NDIR_H # include <ndir.h> # endif #endif 上記の定義を使う場合、プログラム中では変数を(struct directでなく) struct dirent型として定義します。 ディレクトリエントリ名をとるためにはNAMLENマクロに struct direntへのポインタを渡します。 このマクロはSCO Xenixのdirとxライブラリも検査します。

AC_HEADER_MAJOR

Macro

sys/types.hにmajor、minor、それから makedevが定義されておらず、 sys/mkdev.hで定義されている場合、 MAJOR_IN_MKDEVを定義します。 sys/sysmacros.hで定義されている場合、 MAJOR_IN_SYSMACROSを定義します。

AC_HEADER_STDC

Macro

システムにANSI Cヘッダファイルがある場合、STDC_HEADERSを定義します。 具体的には、stdlib.h、stdarg.h、string.h、 それからfloat.hをチェックします。 これらのヘッダがあれば、多分他のANSI Cヘッダファイルもあるでしょう。 このマクロは、string.hでmemchrが定義されているかどうか 調べます(もしmemchrがあればほかのmem系関数もあるでしょう)。 それから、stdlib.hでfreeが定義されているかどうか 調べます(もしokならmallocや他の関連関数もあるでしょう)。 さらに、ctype.hで定義されるマクロがANSI Cの定義どおり、 2^7のビットが立っていても動くかどうか調べます。 ANSI互換のヘッダファイル(とCライブラリ関数)があるかどうか決めるには、 __STDC__でないしにSTDC_HEADERSを使いましょう。 GCCがインストールされているシステムの多くには ANSI Cヘッダファイルがないからです(訳註: つまり、__STDC__が あってもANSI Cヘッダファイルがあるとは限らない、ということ)。 ANSI Cヘッダのないシステムでは、どのヘッダでなにを定義しているかは 全くばらばらです。 ですから、どのヘッダファイルに定義があるか探すよりも、 自分で使う関数を自分で定義した方が簡単です。 あるシステムではANSIとBSDの関数が混在しています。 あるシステムはほぼANSI互換なのにmemmoveがありません。 あるシステムはBSD由来の関数をstring.hやstrings.h註の マクロとして定義しています。 あるシステムではBSD由来の関数しかなく、string.hがありません。 メモリ関係の関数はmemory.hで定義されていたり、string.hで 定義されていたりします。 他にもいろいろ変種があります。 とりあえず、ANSIで定義されている関数が 文字列関係関数をひとつ、 メモリ関係関数を検査すれば多分こと足りるでしょう。 検査が成功すれば、多分他のANSI定義の関数もあるでしょう。 以下をconfigure.inに含めた場合: AC_HEADER_STDC AC_CHECK_FUNCS(strchr memcpy) プログラム中では以下のように定義します: #if STDC_HEADERS # include <string.h> #else # ifndef HAVE_STRCHR # define strchr index # define strrchr rindex # endif char *strchr (), *strrchr (); # ifndef HAVE_MEMCPY # define memcpy(d, s, n) bcopy ((s), (d), (n)) # define memmove(d, s, n) bcopy ((s), (d), (n)) # endif #endif もしプログラム中でmemchr、memset、strtok、 strspnなど、BSD系OSに代用になる関数がないような関数を使う場合、 この定義だけでは足りません。 各関数について配布キット中にプログラムコードを添付しなければなりません。 添付したプログラムを必要なときにだけ使うにはどうすればいいでしょう? (システムのCライブラリに入っている関数の方が最適化されていて 速いかもしれないので) 例えば関数memchrの場合、 memchr.cというファイルを置いて、 AC_REPLACE_FUNCS(memchr)を使えば大丈夫です。

AC_HEADER_SYS_WAIT

Macro

sys/wait.hがあって、POSIX.1互換なら、 HAVE_SYS_WAIT_Hを定義します。 sys/wait.hがない場合、exit statusを保持するのにintでなしに 古いBSDのようにunion waitを使っている場合にはPOSIX.1非互換です。 sys/wait.hがPOSIX.1互換でない場合には、 ヘッダファイルをincludeせず、 POSIX.1マクロを自分で定義しましょう。 例えば: #include <sys/types.h> #if HAVE_SYS_WAIT_H # include <sys/wait.h> #endif #ifndef WEXITSTATUS # define WEXITSTATUS(stat_val) ((unsigned)(stat_val) >> 8) #endif #ifndef WIFEXITED # define WIFEXITED(stat_val) (((stat_val) & 255) == 0) #endif

AC_MEMORY_H

Macro

memcpyやmemcmpなどがstring.hで定義されておらず、 memory.hが存在する場合、NEED_MEMORY_Hを定義します。 このマクロはobsoleteです。 かわりにAC_CHECK_HEADERS(memory.h)を使ってください。 AC_HEADER_STDCの例参照。

AC_UNISTD_H

Macro

unistd.hがあればHAVE_UNISTD_Hを定義します。 このマクロはobsoleteです。 かわりにAC_CHECK_HEADERS(unistd.h)を使ってください。 POSIX.1互換かどうか調べるには以下のようにします: #if HAVE_UNISTD_H # include <sys/types.h> # include <unistd.h> #endif #ifdef _POSIX_VERSION /* Code for POSIX.1 systems. */ #endif _POSIX_VERSIONは、POSIX.1互換のシステムでunistd.hをinclude すると定義されます。 unistd.hがないシステムは間違いなくPOSIX.1非互換です。 でも、一部のPOSIX.1非互換のシステムにはunistd.hがあります。

AC_USG

Macro

strings.h、rindexやbzeroがないシステムなら USGを定義します。 このマクロは string.h、strrchr、memset等が存在すると仮定しています。 USGはobsoleteです。 このマクロでなしに、AC_HEADER_STDCの例題をみてください。

Generic Header Checks

以下のマクロは、特定のヘッダファイル用マクロが定義されていない ヘッダファイルを検査するためのものです。 ヘッダファイルがあるかないかだけでなく、中身もチェックしたい場合、 自力で検査マクロを記述しないといけません(see Writing Tests参照)。

AC_CHECK_HEADER (header-file, [action-if-found [, action-if-not-found]])

Macro

システムヘッダファイルheader-fileがあったら action-if-foundを実行します。 なければaction-if-not-foundを実行します。 単にヘッダファイルがあったときにCプリプロセッサシンボルを定義したいだけなら、 AC_CHECK_HEADERSを使った方がいいでしょう。

AC_CHECK_HEADERS (header-file... [, action-if-found [, action-if-not-found]])

Macro

スペースで区切られた複数のheader-fileのうち、 実際システムヘッダファイルが存在するものについて HAVE_header-file(全部大文字)を定義します。 action-if-foundには、 各々のヘッダファイルがみつかったときに実行したいshellスクリプトを記述します。 action-if-foundをbreakにすると、 最初にヘッダファイルが見つかったところでループを抜けることができます。 action-if-not-foundには、 各ヘッダファイルがみつからなかったときに実行されるshellスクリプトを記述します。

Structures

以下のマクロは特定の構造体や構造体のメンバを検査します。 ここにない構造体を検査したい場合、 AC_EGREP_CPP (see Examining Declarations)やAC_TRY_COMPILE (see Examining Syntax)を使ってください。

AC_HEADER_STAT

Macro

S_ISDIRやS_ISREGなどの、sys/stat.hで定義されている マクロが正しく動かない場合(返り値が嘘の場合)、 STAT_MACROS_BROKENを定義します。 Tektronix UTekV、Amdahl UTS、それからMotorola System V/88が該当します。

AC_HEADER_TIME

Macro

time.hとsys/time.hの両方をincludeしていいなら、 TIME_WITH_SYS_TIMEを定義します。 古いシステムでは、sys/time.hがtime.hをincludeしていて、 しかもtime.hに複数回includeされた場合に対する対処がないことがあります。 この場合、両方のヘッダファイルを明示的にincludeしてはいけません。 このマクロは、例えば、struct timevalやstruct timezoneと、 struct tmを同時に使うプログラムに有効です。 HAVE_SYS_TIME_Hとあわせて使うのがよいでしょう。 HAVE_SYS_TIME_Hは AC_CHECK_HEADERS(sys/time.h)マクロを使うと定義されます。 #if TIME_WITH_SYS_TIME # include <sys/time.h> # include <time.h> #else # if HAVE_SYS_TIME_H # include <sys/time.h> # else # include <time.h> # endif #endif

AC_STRUCT_ST_BLKSIZE

Macro

struct statにメンバst_blksizeが定義されているなら、 HAVE_ST_BLKSIZEを定義します。

AC_STRUCT_ST_BLOCKS

Macro

struct statにメンバst_blocksが定義されているなら、 HAVE_ST_BLOCKSを定義します。 もしなければ、fileblocks.oを出力変数LIBOBJSに足します。

AC_STRUCT_ST_RDEV

Macro

struct statにメンバst_rdevが定義されているなら、 HAVE_ST_RDEVを定義します。

AC_STRUCT_TM

Macro

time.hでstruct tmが定義されていなければ、 TM_IN_SYS_TIMEを定義します。 TM_IN_SYS_TIMEは、struct tmの定義が欲しければ sys/time.hをincludeせよ、という意味です(訳註: 意訳)。

AC_STRUCT_TIMEZONE

Macro

現在のtimezoneを知る方法を推測します。 struct tmにメンバtm_zoneが定義されているなら、 HAVE_TM_ZONEを定義します。 グローバル変数tznameが定義されていたら、HAVE_TZNAMEを定義します。

Typedefs

以下のマクロはCのtypedefを検査します。 検査したいtypedef用に特定のマクロがなくて、 しかも特殊な検査をしたいわけでないのなら、 汎用のtypedef検査マクロが使えます。

• Particular Typedefs: Special handling to find certain types.
• Generic Typedefs: How to find other types.

Particular Typedef Checks

以下のマクロは、sys/types.hとstdlib.hの中のC typedefを 検査します(もしファイルがあれば、ですが)。

AC_TYPE_GETGROUPS

Macro

GETGROUPS_Tを、 getgroupsの引数の型(配列の基底型)にあわせて、 gid_tまたはintに定義します。

AC_TYPE_MODE_T

Macro

mode_tが定義されていない場合、 Cプリプロセッサマクロmode_tをintに#defineします。

AC_TYPE_OFF_T

Macro

off_tが定義されていない場合、Cプリプロセッサマクロoff_tを longに#defineします。

AC_TYPE_PID_T

Macro

pid_tが定義されていない場合、Cプリプロセッサマクロpid_tを intに#defineします。

AC_TYPE_SIGNAL

Macro

signal.hで、関数signalが 「返り値がvoidの関数へのポインタ(つまり、(void (*)())」を 返す場合、RETSIGTYPEをvoidに定義します。 さもなくば、RETSIGTYPEをintに定義します。 シグナルハンドラ関数を定義するときには、 返り値をRETSIGTYPEにしましょう: RETSIGTYPE hup_handler () { ... }

AC_TYPE_SIZE_T

Macro

size_tが定義されていなければ、Cプリプロセッサマクロsize_tを unsignedと定義します。

AC_TYPE_UID_T

Macro

uid_tが定義されていなければ、 Cプリプロセッサマクロuid_tをintに、 gid_tをintに定義します。

Generic Typedef Checks

このマクロは、 特定のtypedef検査マクロが提供されていないtypedefについて調べるときに 使います。

AC_CHECK_TYPE (type, default)

Macro

typeがsys/types.hで定義されていない場合、 Cプリプロセッサマクロを使って C (or C++)のビルトインタイプdefault (例えば、shortとかunsignedとか)に#defineします。 もしヘッダファイルが存在するなら、 stdlib.hやstddef.hについても調べます。

C Compiler Characteristics

以下のマクロはCコンパイラやマシンアーキテクチャの特性を調べます。 以下にない性質を調べたい場合、 AC_TRY_COMPILE (see Examining Syntax) か AC_TRY_RUN (see Run Time)を使ってください。

AC_C_BIGENDIAN

Macro

16ビット幅の値を上位の8ビット(2^15から2^8の8ビット)から 先に格納するCPUアーキテクチャの場合、WORDS_BIGENDIANを定義します。 例えばMotorolaやSPARCなどのCPUがこれにあたります。 IntelやVAXは違います。

AC_C_CONST

Macro

Cコンパイラがconstを完全にサポートしていなければ、 constを空に#defineします。 世の中にはconstをサポートしているのに__STDC__を定義していない Cコンパイラや、 逆にconstを完全にはサポートしていないのに__STDC__を定義している Cコンパイラがあります。 AC_C_CONSTを使えば、プログラム中では必ずCコンパイラがconstを サポートしているつもりで、constを書けば大丈夫です。 Cコンパイラがconstをサポートしていなければ、 constはMakefileまたはconfiguration header fileで空にされます。

AC_C_INLINE

Macro

Cコンパイラがinlineをサポートしていればなにもしません。 inlineがサポートされておらず、__inline__あるいは __inlineがサポートされていれば、 inlineを__inline__か__inlineに#defineします。 どちらもサポートされていなければ空にします。

AC_C_CHAR_UNSIGNED

Macro

Cの型charが符号なし(unsigned)だったら、 __CHAR_UNSIGNED__を定義します。 ただし、Cコンパイラが既に__CHAR_UNSIGNED__を 定義していたらなにもしません。

AC_C_LONG_DOUBLE

Macro

Cコンパイラがlong double型をサポートしていたら、 HAVE_LONG_DOUBLEを定義します。 世の中には __STDC__を定義していないのに long doubleをサポートしているCコンパイラや、 __STDC__を定義しているのに long doubleをサポートしていないCコンパイラがあります。

AC_C_STRINGIZE

Macro

Cプリプロセッサが文字列化演算子をサポートしているなら HAVE_STRINGIZEを定義します。文字列化演算子は# で、以下のよ うなマクロ定義の中で見出せます。 #define x(y) #y

AC_CHECK_SIZEOF (type [, cross-size])

Macro

SIZEOF_uctypeをC(またはC++の)基底型typeの バイトサイズにします。 typeは例えばintとかchar *とかです。 コンパイラがtypeを知らない場合、SIZEOF_uctypeは 0になります。 uctypeは、typeの小文字を大文字に、スペースを下線_に、 アスタリスク(*)をPにしたものです。 クロスコンパイルをしている場合、 cross-sizeを指定していればそれが使われます。 クロスコンパイルをしている場合に cross-sizeが指定されていないと、 configureはエラーメッセージを出して終了します。 例えば、DEC Alpha AXPで AC_CHECK_SIZEOF(int *) とすると、SIZEOF_INT_Pは8になります。

AC_INT_16_BITS

Macro

Cの型intが16ビットの場合、INT_16_BITSを定義します。 このマクロはobsoleteです。 かわりにより汎用的なAC_CHECK_SIZEOF(int)を使ってください。

AC_LONG_64_BITS

Macro

Cの型long intが64ビットの場合、LONG_64_BITSを定義します。 このマクロはobsoleteです。 かわりにより汎用的なAC_CHECK_SIZEOF(long)を使ってください。

Fortran 77 Compiler Characteristics

以下のマクロはFortran 77コンパイラの特性を検査します。ここに列挙されてい ない特性を検査するには、AC_TRY_COMPILE(see Examining Syntax) や AC_TRY_RUN (see Run Time) を使います。まず現在選択されてい る言語がFortran 77 AC_LANG_FORTRAN77 に設定されていることを確かめ てください(see Language Choice)。

AC_F77_LIBRARY_LDFLAGS

Macro

Fortran 77プログラムや共有ライブラリを首尾良くリンクするのに必要な Fortran 77 固有のものやランタイムなライブラリのための リンカフラグ(例えば、-Lや-l)を決定します。 出力変数FLIBSはこれらのフラグに設定されます。 このマクロは例えば、1つのプログラムや共有ライブラリでC++とFortran 77ソー スコードを混合する必要がある場合に使われることを意図されています。 (see Mixing Fortran 77 With C and C++)。 例えば、もしC++とFortran 77コンパイラからのオブジェクトファイルが一緒に リンクされなければならないなら、C++コンパイラ/リンカはリンクのために使わ れなければなりません(C++特有のものは、リンク時にグローバルコンストラクタ、 インスタンステンプレート、例外処理等を呼び出す必要が生じるためです)。 しかし、Fortran 77イントリンシックとランタイムライブラリも同様にリンクす る必要がありますが、C++コンパイラ/リンカは、デフォルトでFortran 77ライブ ラリを加える方法を知りません。そのため、マクロ AC_F77_LIBRARY_LDFLAGSは、これらのFortran 77ライブラリを決定する ため作られました。

System Services

The following macros check for operating system services or capabilities.

AC_CYGWIN

Macro

Cygwin環境のための検査をします。もしCygwin環境ならば、シェル変数 CYGWIN をyesに設定します。もしそうでないならCYGWIN を空文字列に設定します。

AC_EXEEXT

Macro

.c、 .o、 .objファイルが取り除かれた後で(訳註: ？？)コンパイラの出力の元 になる代用変数EXEEXTを定義します。典型的にはUNIXなら空文字列に、 Win32やOS/2なら.exeに設定します。

AC_OBJEXT

Macro

.cファイルが取り除かれた後で(訳註: ？？)コンパイラの出力の元になる代用変 数OBJEXTを定義します。典型的にはUNIXならo に、Win32なら objに設定します。

AC_MINGW32

Macro

MingW32コンパイラ環境のための検査をします。もしMingW32コンパイラ環境なら ばシェル変数MINGW32をyesに設定します。そうでないなら MINGW32を空文字列に設定します。

AC_PATH_X

Macro

X Window Systemのincludeファイルとライブラリがどこにあるか調べます。 configureの呼び出し時に、ユーザが --x-includes=dirや--x-libraries=dirを 指定していたら、指定されたディレクトリを使います。 片方または両方とも指定されていなかったら、 決まっていない値を、 簡単なImakefileをxmkmfに食わせ、 生成されたMakefileを調べることで定めます。 もしこれが(xmkmfがないとかの理由で)失敗したら、 一般的にX Window Systemが置かれるディレクトリを探します。 いずれかの方法で値が決まったら、 shell変数x_includesとx_librariesに結果を格納します。 ただし、ディレクトリがコンパイラのデフォルトサーチパスに入っている場合には 値は設定されません。 上記の方法でもディレクトリがわからなかった場合や、 ユーザが--without-xを指定していた場合、 no_xをyesに設定します。 no_xはyesでなければ空になります。

AC_PATH_XTRA

Macro

AC_PATH_Xの拡張版です。 X_CFLAGSにXが必要とするCコンパイラのフラグを、 X_LIBSにリンカのフラグを設定します。 Xがない場合にはX_CFLAGSに-DX_DISPLAY_MISSINGを追加します。 このマクロは、 Xを使うプログラムをコンパイルするときに特別なライブラリが必要なら、 それもチェックしてX_EXTRA_LIBSに追加します。 X11R6特有のライブラリのうち-lX11より前に指定しないといけない ものがあったら、 それをX_PRE_LIBSに追加します。

AC_SYS_INTERPRETER

Macro

このシステムに、 「スクリプトファイルの先頭に#! /bin/cshのような行を付け加えることで、 スクリプトを実行するshellを選択する」機能がついているかどうか調べます。 このマクロを使用したあとは、 configure.inの中に記述するshellスクリプトの中で、 shell変数interpvalを使えます。 このshell変数の値はシステムが#!をサポートしていればyes、 していなければnoになります。

AC_SYS_LONG_FILE_NAMES

Macro

システムが14文字以上のファイル名をサポートしていたら、 HAVE_LONG_FILE_NAMESを定義します。

AC_SYS_RESTARTABLE_SYSCALLS

Macro

signalで割り込まれたシステムコールが自動で再開されるなら、 HAVE_RESTARTABLE_SYSCALLSを定義します。

UNIX Variants

以下のマクロは、ヘッダファイルやライブラリに癖があるなどの理由で、 特別な取扱が必要なOSについてチェックします。 これらのマクロは無理矢理作った逃げ道です (訳註: wartだから「目の上のたんこぶ」とか言ってもいいのだけれど、 それでは意味が通じない)。 本来はよりシステマチックに、ライブラリやヘッダファイルの内容および機能や、 OSで提供される環境について調べるべきです。

AC_AIX

Macro

OSがAIXだったら、_ALL_SOURCEを定義します。 BSDの機能の一部が使えます。 Cコンパイラを実行するマクロより前に使わないといけません。

AC_DYNIX_SEQ

Macro

OSがDynix/PTX (Sequent UNIX)だったら、 -lseqを出力変数LIBSに追加します。 このマクロはobsoleteです。 かわりにAC_FUNC_GETMNTENTを使いましょう。

AC_IRIX_SUN

Macro

OSがIRIX (Silicon Graphics UNIX)だったら、 -lsunを出力変数LIBSに追加します。 このマクロはobsoleteです。 getmntentを使いたいためにこのマクロを使っていたのなら、 AC_FUNC_GETMNTENTを使いましょう。 NISサポート入りのパスワード/gid系関数を使いたければ、 AC_CHECK_LIB(sun, getpwnam)を使いましょう。

AC_ISC_POSIX

Macro

OSがPOSIXサポート入りのISC UNIX(POSIXized ISC UNIX)上だったら、 _POSIX_SOURCEを定義し、-posix(GNU Cコンパイラ用) または-Xp(他のCコンパイラ用)をCCに追加します。 AC_PROG_CCより後で、しかもCコンパイラを呼び出す他のマクロより先に 呼び出さねばなりません。

AC_MINIX

Macro

OSがMinixだったら、_MINIXと_POSIX_SOURCEを定義し、 _POSIX_1_SOURCEを2に定義します。 こうするとPOSIXの機能が使えます。 Cコンパイラを実行するマクロより前に使わないといけません。

AC_SCO_INTL

Macro

OSがSCO UNIXだったら、-lintlをLIBSに追加します。 このマクロはobsoleteです。 かわりにAC_FUNC_STRFTIMEを使いましょう。

AC_XENIX_DIR

Macro

OSがXenixだったら、-lxを出力変数LIBSに追加します。 また、dirent.hが使われていたら、-ldirを出力変数LIBSに 追加します。 このマクロはobsoleteです。 AC_HEADER_DIRENTを使いましょう。

Writing Tests

あなたの必要としている検査項目が既存のマクロで実現されていない場合、 自分であたらしいマクロを書かねばなりません。 以下のマクロは、マクロの基本部品です 以下のマクロは、他のマクロ内でOS/コンパイラの機能を検査したり、 結果を出力したりするのに使われています。

この章では、推奨されるマクロの書き方、 それから既存のマクロがどうして現在あるように記述されているのかについて 述べています。 既存のマクロがどのように書かれているのか見ることで、 どうやってAutoconfのマクロを記述すべきか学べるでしょう。 Autoconfのテストでなにかがうまくいかなかったら、 マクロがなにを仮定しているのか理解するのに この章の内容が役立つかもしれません。 マクロが仮定していることを理解すれば、 マクロの問題点をどう解くべきなのかを知るにも役立つでしょう (訳註: 相当意訳)。

以下のマクロは、Cコンパイラの出力を調べます。 以下のマクロは結果をキャッシュしません(see Caching Results)。 なぜなら、これらのマクロからは検査している内容がわからないし キャッシュ変数名も決められないからです。 Cコンパイラの特定の機能を調べるマクロは、結果をキャッシュしますし、 なにを調べているのかメッセージも出力されます。

複数のソフトウェアパッケージで利用できる検査を書いた場合、 新しいマクロを定義するのがよいでしょう。 どうやるかはSee Writing Macros参照。

• Examining Declarations: Detecting header files and declarations.
• Examining Syntax: Detecting language syntax features.
• Examining Libraries: Detecting functions and global variables.
• Run Time: Testing for run-time features.
• Portable Shell: Shell script portability pitfalls.
• Testing Values and Files: Checking strings and files.
• Multiple Cases: Tests for several possible values.
• Language Choice: Selecting which language to use for testing.

Examining Declarations

AC_TRY_CPPは特定のヘッダファイルが存在するか調べるためにあります。 ヘッダファイルひとつづつについて調べることもできますし、 ひとつの目的のために調べるのなら複数のヘッダファイルをまとめて 調べることもできます。

AC_TRY_CPP (includes, [action-if-true [, action-if-false]])

Macro

includesには CまたはC++の#include文(訳註: ほんとは文じゃないね)と 定義文(訳註: #defineとか)を記述します。 他の文を記述しても構いませんが、多分意味ないでしょう。 includesのところにはshell変数、 backquote、backslashによる置換が働きます (訳註: 置換を避けたければ[と]で囲め、ということです)。 プリプロセッサが処理中にエラーメッセージを出さなければ、 shellコマンドaction-if-trueが実行されます。 エラーがあればaction-if-falseが実行されます。 このマクロはCPPFLAGSを使いますが、CFLAGSは使いません。 -gとか-Oは多くのCプリプロセッサで無効だからです。

次のマクロはヘッダファイルに特定の定義(typedef、構造体、構造体メンバ、 関数プロトタイプ)が入っているかどうか調べます。 ヘッダファイルを直接grepせずに、AC_EGREP_HEADERを使いましょう。 システムによっては、調べたいシンボルが、あなたがgrepしている ヘッダファイルから#includeされている他のヘッダファイルで 定義されているかもしれません。

AC_EGREP_HEADER (pattern, header-file, action-if-found [, action-if-not-found])

Macro

header-fileをCプリプロセッサに通した結果がpatternと マッチすれば、action-if-foundを実行します。 マッチしなければ、action-if-not-foundを実行します。 patternはegrepの正規表現です。

ヘッダファイルで定義されたり、Cプリプロセッサで前もって定義されている Cプリプロセッサシンボルを調べる場合、 AC_EGREP_CPPを使いましょう。 以下に例題があります:

AC_EGREP_CPP(yes,
[#ifdef _AIX
  yes
#endif
], is_aix=yes, is_aix=no)

AC_EGREP_CPP (pattern, program, [action-if-found [, action-if-not-found]])

Macro

programはCまたはC++のプログラムテキストです。 programのところにはshell変数、 backquote、backslashによる置換が働きます。 programをプリプロセッサに通した結果がpatternと マッチすれば、action-if-foundを実行します。 マッチしなければ、action-if-not-foundを実行します。 patternはegrepの正規表現です。 このマクロは、もしまだ呼ばれていないなら、 AC_PROG_CPPまたはAC_PROG_CXXCPPを呼び出します。 どちらを呼ぶかはどちらの言語を選んでいるかに依存します (see Language Choice)。

Examining Syntax

「特定のキーワードを認識するかどうか」など、 C、C++ や Fortran 77コンパイラの文法的な機能を調べるためには、 AC_TRY_COMPILEを使ってそのキーワードや機能を使う小さなプログラムを コンパイルしてみましょう。 AC_TRY_COMPILEを使うと、特定のシステムにしかない 構造体や構造体メンバを調べることもできます。

AC_TRY_COMPILE (includes, function-body, [action-if-found [, action-if-not-found]])

Macro

このマクロは、 関数の中身がfunction-bodyの記述からなるようなテスト用のC、C++、 Fortran 77プログラム(現在選択されている言語に依存 see Language Choice)を書き出し、それがコンパイラでコンパイルできるかどうか調べます。 CとC++のため、includesはfunction-bodyのコードが必要とする、 あらゆる#includeです(現在選択されている言語がFortran 77の場合は無 視されます)。このマクロは、現在選択されている言語がCやC++の場合、 CFLAGSやCXXFLAGSも使用し、コンパイル時にはCPPFLAGS も使用します。Fortran 77が現在選択されている言語の場合、コンパイル時に FFLAGSを使用します。 もしコンパイルできたなら、shellコマンドaction-if-foundを実行します。 もしできなかったらaction-if-not-foundを実行します。 このマクロはリンクを行おうとはしません(コンパイルしかしません)。 テストのためにリンクもしたい場合、AC_TRY_LINKを使ってください (see Examining Libraries)。

Examining Libraries

ライブラリ、関数、またはグローバル変数を調べるために、 Autoconfの生成するconfigureスクリプトは、小さなプログラムを コンパイルしてリンクしてみます。 Metaconfigは(デフォルトでは)Cライブラリに対しnmやarを 実行することで提供されている関数を調べますが、 AutoconfはMetaconfigとは違います。 実際に関数をリンクしてみる方が判定方法として確実です。 なぜなら、nmやarのさまざまなオプションや出力形式、 それから標準ライブラリの置き場所に関する差異を取り扱わなくて済みます。 クロスコンパイルできるかどうかも調べられます。 それに、必要なら関数の実行時の挙動を調べることもできます。 そのかわりに、実際関数をリンクしてみるのは、 ライブラリを一度調べればいいnm式よりも遅いです。

ごく少数のシステムでは、リンク時に発見できない関数があってもリンカが 「失敗」とのexitステータスを変えしません。 このようなシステムでは、Autoconfで生成されたスクリプトが使えません。 ただし、このようなシステムの一部では、特定のコマンドラインオプションを 与えるとリンカが正しくexitステータスを返すようになります。 Autoconfは現在この問題を自動的に解決していません。 ユーザがこの問題にであった場合、環境変数LDFLAGSにリンカが必要とする オプションを設定して渡してやることで解決できるでしょう (例えばMIPS RISC/OSの場合-Wl,-dn)。

関数とグローバル変数について調べるためには、AC_TRY_LINKを使って テストプログラムをコンパイルしてみます。 このマクロはライブラリの検査(see Libraries)のためにAC_CHECK_LIBの内部でも使われています。 このためには、LIBに調べたいライブラリ名を一時的に追加し、 テストプログラムをリンクしてみます。

AC_TRY_LINK (includes, function-body, [action-if-found [, action-if-not-found]])

Macro

このマクロは、 現在選択されている言語(see Language Choice)によって、関数の中身が function-bodyの記述からなるようなテスト用のCプログラムを書き出しま す。 CやC++では、includeはfunction-bodyのコードで必要となる任意の #include文です(現在選択されている言語がFortran 77の場合は無< 視さ れます)。もし現在選択されている言語がCやC++ならば、このマクロは CFLAGSやCXXFLAGSも使用し、コンパイル時には、 CPPFLAGS も使用します。もしFortran 77が現在選択されている言語なら ば、コンパイル時にFFLAGSを使用します。しかし、LDFLAGSと LIBSは、全ての場合でリンク時に使います。 もし成功したなら、shellコマンドaction-if-foundを実行します。 もしできなかったらaction-if-not-foundを実行します。

AC_TRY_LINK_FUNC (function, [action-if-found [, action-if-not-found]])

Macro

現在の言語に依存して(see Language Choice)、本体がプロトタイプからな り、functionの呼び出しを含むプログラムの、コンパイルとリンクが可能 かどうかを知るために、テストプログラムを作ります。 もし成功したなら、shellコマンドaction-if-foundを実行します。 もしできなかったらaction-if-not-foundを実行します。

AC_TRY_LINK_FUNC (function, [action-if-found [, action-if-not-found]])

Macro

functionをリンクする、小さなプログラムのコンパイルとリンクを試みま す。もしファイルのコンパイルとリンクが成功したならば、シェルコマンドの action-if-foundを実行し、それ以外ではaction-if-not-foundを実 行します。

AC_COMPILE_CHECK (echo-text, includes, function-body, action-if-found [, action-if-not-found])

Macro

これはAC_TRY_LINKに類似した、obsoleteなマクロです。 AC_COMPILE_CHECKは、echo-textが空でなければ、テストの前に checking for echo-textと標準出力に表示します。 テストの進行状況や結果を表示するには、 AC_MSG_CHECKINGとAC_MSG_RESULTを使いましょう (see Printing Messages)。

Checking Run Time Behavior

システムの機能に癖やバグがある場合など、 システムが実行時にどう振舞うのか知らないといけないことがあります。 可能なら、コンパイル時でなしにパッケージの実行時に検査しましょう。 例えば、マシンのendianをプログラムの初期化時に調べることは可能です。

実行時のふるまいをどうしてもパッケージのコンパイル前に調べたい場合、 テストプログラムを書き、AC_TRY_RUNを使ってコンパイルして 実行し、結果を調べることができます。 可能な限りこの種のテストプログラムを使うことは避けましょう。 あなたのパッケージをクロスコンパイルできなくなります。

• Test Programs: Running test programs.
• Guidelines: General rules for writing test programs.
• Test Functions: Avoiding pitfalls in test programs.

Running Test Programs

システムが実行時にどう振舞うのかをコンパイル時に調べるためには、 以下のマクロを使いましょう。

AC_TRY_RUN (program, [action-if-true [, action-if-false [, action-if-cross-compiling]]])

Macro

programにはCプログラムコードを指定します。 programに対してはshell変数やbackquoteによる置換が働きます。 programのコンパイルとリンクが成功し、 実行したときにexitステータス0が返ったら、 shellコマンドaction-if-trueを実行します。 さもなくば、action-if-falseを実行します。 このとき、プログラムのexitステータスはshell変数$?に入っています。 このマクロは CFLAGS、CXXFLAGS、CPPFLAGS、LDFLAGS、それから LIBSを利用します。 (クロスコンパイルしている等の理由で)現在使っているCコンパイラが、 configureを実行しているシステムで動かないコードを出力する場合には、 テストプログラムは実行されません。 省略可能なshellコマンドaction-if-cross-compilingが指定された場合、 かわりにshellコマンドが実行されます。 action-if-cross-compilingが指定されていない場合にはconfigureは エラーメッセージを出力し終了します。

実行時の振舞いを調べられないクロスコンパイル時のために、 悲観的なデフォルト値を用意しておきましょう。 これは、 AC_TRY_RUNの最後の引数(action-if-cross-compiling)を 与えることで達成できます。 autoconfはconfigureスクリプトを生成する際、 action-if-cross-compilingの指定のないAC_TRY_RUNがあるたび 警告を出します。 警告を無視しても構いませんが、その場合ユーザはあなたのパッケージを クロスコンパイルできなくなります。 Autoconfと一緒に配布されているマクロには、 このような警告を出すマクロがごく少数あります。

クロスコンパイルのためにパッケージを設定する場合、 正規化されたシステム名(see Manual Configuration)によって action-if-cross-compilingで決める値を変えることができます。 または、各ターゲットシステムにあわせた正しい値を書いた キャッシュファイルを置いておくこともできます(see Caching Results)。

AC_TRY_RUNは、Autoconf標準添付のマクロを含めて 他のマクロ内部から呼び出されることがあります。 このような場合に、クロスコンパイル時のためのデフォルト値を設定するためには、 AC_TRY_RUNより前にAC_PROG_CCを呼んでおくとよいでしょう。 AC_PROG_CCを呼んだあと、shell変数cross_compileが yesだったら、AC_TRY_RUNを呼ばず、 かわりの方法を使って設定結果の値を決めるのです。

AC_C_CROSS

Macro

このマクロはobsoleteです。 何もしません。

Guidelines for Test Programs

テストプログラムは標準出力になにも書き出してはいけません。 テストが成功したら0を、成功しなかったら0以外を返してexitすべきです。 これはテストの成功と、core dumpや他の理由によるテスト失敗とを 明確に区別するためです。 セグメンテーションフォールトやその他が起きたときにはexit statusは 0以外になります。 テストプログラムは関数mainからのreturnでなしに exitで終了すべきです。 一部のシステム(少なくとも古いSun)では関数mainの返り値は無視されます。

テストプログラムは#ifや#ifdefを使って、 既に実行された他のテストで定義されたプリプロセッサマクロを参照できます。 例えば、AC_HEADER_STDCを呼び出したら、 以後configure.inの中で記述するテストプログラムでANSI Cヘッダファイルを #includeすることができます:

#if STDC_HEADERS
# include <stdlib.h>
#endif

テストプログラムがデータファイルを使ったり作ったりしないといけない場合、 conftestで始まるファイル名、例えばconftestdataを使いましょう。 configureスクリプトは、外部のテストプログラムが終了したときや スクリプトが中断されたときに、rm -rf conftest*を実行して データファイルを消去します。

Test Functions

テストプログラム中の関数定義をするときは、 C処理系の場合とC++処理系の場合とを条件分けして定義しなければなりません。 実際のところは、テストプログラム中で引数をとる関数を 使うことはめったにありません。

#ifdef __cplusplus
foo(int i)
#else
foo(i) int i;
#endif

プロトタイプ宣言についても同様に条件分けしなければなりません。 C++処理系はC linkageの関数プロトタイプの前にextern "C"が必要だからです (訳註: ちょと補足)。 extern "C"が入っていないようなヘッダファイルを #includeしないように注意してください。

#ifdef __cplusplus
extern "C" void *malloc(size_t);
#else
char *malloc();
#endif

テストプログラム中で、(単に関数があるかないか調べるために) 不正な引数を使って関数を呼び出す場合、 間違って関数が呼び出されないように注意してプログラムを記述してください。 これは、目的の関数を、絶対呼び出されない関数fooの中から 呼び出すよう記述することで実現できます。 exitの後で目的の関数を呼び出すのではテストになりません。 GCCバージョン2は関数exitのあと処理が戻らないことを知っていて、 exitと同じブロックの以後の部分をコンパイルしない最適化を するからです。

ヘッダファイルを#includeして、その中でプロトタイプ宣言されている 関数を呼び出す場合、 プロトタイプ宣言違反でコンパイルエラーが発生しないよう、 (引数が単に0であっても)引数の個数は定義どおりにしてください。 GCCバージョン2では、インライン展開される一部の関数(memcpyとか)について コンパイラ内部でプロトタイプ宣言を持っています。 このような関数の有無をチェックする場合、 正しい個数の引数を渡すか、charなどに返り値を変えて再定義してください (訳註: 返り値の宣言変えて意味あるのか?)。

Portable Shell Programming

自分でテストマクロを記述する場合、 shellスクリプトの移植性を高く保つためにいくつかの記法を使わないように しないといけません。 Bourne shellと(BashやKorn shell等の)上位互換のshellは 長年発達してきましたが、トラブルを避けるため、 1977年ごろのUNIX version 7以降に追加された機能は使わないようにしてください。 shellスクリプト内関数、alias、character classの反転 (訳註: 「negated character classes」)、それから 必ずしも全てのBourne shell互換shellに入っていない機能は使うべきではありません。 最小公約数的なスクリプトを書くように心がけてください。 一部のshellではunsetすら使えません! スクリプトインタプリタを指定するための#!の後には、 以下のようにスペースをつけてください:

#! /usr/bin/perl

configureスクリプトからは、ごく少数の外部プログラムしか 呼び出してはいけません。 呼び出していいプログラムのリストは See Utilities in Makefilesにあります。 この制限により、プログラム間の依存関係を最小限にとどめ、 ユーザがパッケージをインストールするために 前もって用意しないといけないプログラムを最小限に抑えることができます。

呼び出していい外部プログラムのリストに載っているプログラムについても、 最低限の共通な機能だけを使いましょう(訳註: すごく意訳)。 例えば、lnが-fをサポートしているとか catにコマンドラインオプションがあるとか仮定してはいけません。 sedスクリプト内には、コメントや8文字以上のラベルがあってはいけません。 grep -sで出力を抑制しようとしてはいけません。 System Vではgrep -sは出力を抑制せず、エラーメッセージだけ 抑制するからです。 かわりに、grepの標準出力と標準エラー出力の両方を/dev/nullに リダイレクトしましょう (標準エラー出力もリダイレクトするのは、エラー発生時に出力を出さないように するためです)。 grepのexitステータスで、matchする文字列がみつかったかどうか 確認しましょう。

Testing Values and Files

configureスクリプトは多くのファイルや文字列の特性を検査する必要が あります。ここではそれら検査を行うときに用心するいくつかの移植性の問題を あげます。

testプログラムは多くのファイルや文字列をテストする手段です。それ はしばしば別の名前[で実行されます。しかしAutoconfコードの中でその 名前を使うことはそれがm4のクォート文字の1つであるので災いを招きま す。

testを使った多重検査が必要なら、testプログラムの演算子 -aと-oの代わりに、シェル演算子&&と||で組み合 わせてください。System V では-aと-oの優先順位が単項演算子 に関連して間違っています。したがってPOSIXはそれらを記していません。 だからそれらを使うことは移植性を損ないます。 もしあなたが&&と||を同じ文で組み合わせるなら、それらが 同じ優先順位を持つことを覚えておいてください。

configureスクリプトがクロスコンパイルをサポートできるようにするに は、ターゲットシステムの代わりにホストシステムの特性を検査するべきではあ りません。しかし、時々あなたはいくつかの恣意的なファイルが存在するかどう かを検査する必要を見つけるかも知れません。そうするにはtest -f や test -rを使います。test -xを使っては行けません。なぜなら 4.3BSDそれを持たないので。

別の移植性を損なうシェルプログラミング構文は以下です。

var=${var:-value}

その意味はまだ値が設定されていないときにだけvarにvalueを設定 し、varがなにか値を持っていれば、空文字列でさえ、そのままにしてお きます。古いBSDのシェル、Ultrix shを含みます、は、コロンを受け付けず、 不平を言って終了します。移植性のある同等なものは以下です。

: ${var=value}

Multiple Cases

Some operations are accomplished in several possible ways, depending on the UNIX variant. Checking for them essentially requires a "case statement". Autoconf does not directly provide one; however, it is easy to simulate by using a shell variable to keep track of whether a way to perform the operation has been found yet.

UNIXの種類に依存して、いくつかの処理は可能な方法で達成されます。本質的に それを調べるためには、"case文"が必要です。Autoconfは直接それを供給しま せん。しかし、実行する処理が見つかったかどうかの追跡を記録するため、シェ ル変数を使って簡単にシミュレーションができます。

ここに、調べる必要があるもののまだ残っているcaseの追跡を記録するため、シェ ル変数fstypeを使用する例があります。

AC_MSG_CHECKING(how to get filesystem type)
fstype=no
# The order of these tests is important.
AC_TRY_CPP([#include <sys/statvfs.h>
#include <sys/fstyp.h>], AC_DEFINE(FSTYPE_STATVFS) fstype=SVR4)
if test $fstype = no; then
AC_TRY_CPP([#include <sys/statfs.h>
#include <sys/fstyp.h>], AC_DEFINE(FSTYPE_USG_STATFS) fstype=SVR3)
fi
if test $fstype = no; then
AC_TRY_CPP([#include <sys/statfs.h>
#include <sys/vmount.h>], AC_DEFINE(FSTYPE_AIX_STATFS) fstype=AIX)
fi
# (more cases omitted here)
AC_MSG_RESULT($fstype)

Language Choice

CとC++の両方を使うパッケージは、両方のコンパイラの特徴をテストする必要が あります。Autoconfが生成したconfigureスクリプトは、デフォルトでC の特徴を調べます。以下のマクロはconfigure.inのテストで、使ってい る言語のコンパイラを決定します。

AC_LANG_C

Macro

CCとCPPを使うコンパイルテストを行い、拡張子が.cのテ ストプログラムを使います。もし実行されたならば、AC_PROG_CCが求め た値をシェル変数cross_compilingに、それ以外では空に設定します。

AC_LANG_CPLUSPLUS

Macro

CXXとCXXCPPを使うコンパイルテストを行い、拡張子が.C のテストプログラムを使います。もし実行されたならば、AC_PROG_CC が 求めた値をシェル変数cross_compilingに、それ以外では空に設定します。

AC_LANG_FORTRAN77

Macro

Do compilation tests using F77 and use extension .f for test programs. Set the shell variable cross_compiling to the value computed by AC_PROG_F77 if it has been run, empty otherwise. F77を使うコンパイルテストを行い、拡張子が.fのテストプログ ラムを使います。もし実行されたならば、AC_PROG_CCが求めた値をシェ ル変数cross_compilingに、それ以外では空に設定します。

AC_LANG_SAVE

Macro

(AC_LANG_C、AC_LANG_CPLUSPLUSやAC_LANG_FORTRAN77が 設定するように)現在の言語をスタックに覚えさせます。現在の言語を変更しま せん。このマクロとAC_LANG_RESTOREは、特定の言語を一時的に切替える 必要があるマクロで使ってください。

AC_LANG_RESTORE

Macro

AC_LANG_SAVEが設定するように、スタックのトップに保存されている言 語を選択し、スタックから削除します。このマクロは、AC_LANG_SAVEが 最後に呼ばれた時、最も最近実行されたAC_LANG_C、 AC_LANG_CPLUSPLUSやAC_LANG_FORTRAN77と同じです。 このマクロをAC_LANG_SAVEより多くの回数、呼び出さないでください。

AC_REQUIRE_CPP

Macro

現在、テストに使われるプリプロセッサの存在を保証します。 AC_PROG_CPPやAC_PROG_CXXCPPの引数で、現在の言語に依存して、 AC_REQUIRE(see Prerequisite Macros)を呼び出してください。

Results of Tests

一度configureが特徴の存在を定義した場合、どのようにしてその情報を 記録するのでしょう。それは4種類あり、それらは、Cプリプロセッサシンボルの 定義、出力ファイルで変数をセット、configure実行時のキャッシュファ イルに結果を保存、テスト結果をユーザーに知らせるメッセージの出力です。

• Defining Symbols: Defining C preprocessor symbols.
• Setting Output Variables: Replacing variables in output files.
• Caching Results: Speeding up subsequent configure runs.
• Printing Messages: Notifying users of progress or problems.

Defining C Preprocessor Symbols

特徴テストの応答をもたらす普通の行動は、テストの結果を示すCプリプロセッ サシンボルを定義することです。それはAC_DEFINEや AC_DEFINE_UNQUOTEDと呼ばれるもので行います。

デフォルトで、AC_OUTPUTはマクロが定義したシンボルを出力変数 DEFSに置き、それぞれのシンボルで、それは -Dsymbol=valueを含みます。Autoconf バージョン1と異な り、configureが実行中に定義する変数DEFSはありません。 AutoconfマクロがあるCプリプロセッサシンボルを既に定義しているかどうか調 べるため、以下の例のように適切なキャッシュ変数の値をテストしてください。

AC_CHECK_FUNC(vprintf, AC_DEFINE(HAVE_VPRINTF))
if test "$ac_cv_func_vprintf" != yes; then
AC_CHECK_FUNC(_doprnt, AC_DEFINE(HAVE_DOPRNT))
fi

AC_CONFIG_HEADERが呼び出される場合、DEFSを作る代わりにテン プレートファイルに#define文で正しい値を代入したヘッダファイルを AC_OUTPUTで作ってください。この種類の出力の詳細は、 See Configuration Headers.

AC_DEFINE (variable [, value [, description]])

Macro

Cプリプロセッサ変数variableを定義します。valueが与えられる場 合は、variableにその値を(逐語的に)セットし、それ以外では1にセット します。valueは改行リテラルを含むべきではなく、 AC_CONFIG_HEADERを使わない場合はmakeが処理してしまうので、 #文字を含めるべきではありません。シェル変数(m4の引用符文字 [や]を含む定義値が必要なもの)を使うために、代わりに AC_DEFINE_UNQUOTEDを使ってください。descriptionは、 AC_CONFIG_HEADERを使う場合のみ役に立ちます。この場合、 descriptionは、生成されたconfig.h.inにマクロ定義前のコメン トとして置かれます。マクロをacconfig.hに記述する必要はありません。 次の例は、Cプリプロセッサ変数EQUATIONを文字定数 "$a > $b" と定義します。 AC_DEFINE(EQUATION, "$a > $b")

AC_DEFINE_UNQUOTED (variable [, value [, description]])

Macro

AC_DEFINEに似ていますが、3つのシェル拡張は、variableと valueで一度だけ実行されるもので、変数の拡張($)、コマンドの 代入(`)と、バックスラッシュエスケープ(\)です。値のシングル とダブルクオートの文字列は特別な意味を持ちません。variableや valueがシェル変数の時は、AC_DEFINEの代わりにこのマクロを使っ てください。以下が例です。 AC_DEFINE_UNQUOTED(config_machfile, "${machfile}") AC_DEFINE_UNQUOTED(GETGROUPS_T, $ac_cv_type_getgroups) AC_DEFINE_UNQUOTED(${ac_tr_hdr})

Bourneシェルの構文の特異性のため、AC_DEFINEや AC_DEFINE_UNQUOTEDの他のマクロやシェルコードからの呼び出しをるた め、セミコロンを使わないでください。それは、configureスクリプトの 結果、構文エラーの原因となります。以下のようにします。

AC_CHECK_HEADER(elf.h, AC_DEFINE(SVR4) LIBS="$LIBS -lelf")

あるいはこのようにします。

AC_CHECK_HEADER(elf.h,
  AC_DEFINE(SVR4)
  LIBS="$LIBS -lelf")

この代わりです。

AC_CHECK_HEADER(elf.h, AC_DEFINE(SVR4); LIBS="$LIBS -lelf")

Setting Output Variables

テストの結果を記録する一つの方法は、出力変数を設定することで、そ れは、configureが出力したファイルの中で、値が代入されたシェル変数 です。以下の2つのマクロが新しい出力変数を作ります。利用可能な出力変数 のリストは、See Preset Output Variables.

AC_SUBST (variable)

Macro

シェル変数から出力変数を作ります。AC_OUTPUTは変数variable を出力ファイルに代入します(通常、一つ以上のMakefileです)。これは、 AC_OUTPUTが呼び出されたとき、AC_OUTPUTがシェル変数 variableの値を持つ入力ファイルの@variable@のインス タンスを置換することを意味します。variableの値は改行を含むべきでは ありません。

AC_SUBST_FILE (variable)

Macro

シェル変数から出力ファイルを作るもう一つの方法です。出力ファイルに、シェ ル変数variableで名付けられたファイルの内容をAC_OUTPUTに挿入 させます(代入ではありません)。これは、AC_OUTPUTが呼び出されたとき、 AC_OUTPUTが、シェル変数variableの値を持つ入力ファイルの内容 を(Makefile.inのような)出力ファイルの@variable@の インスタンスを置換することを意味します。挿入するファイルがない場合、変数 を/dev/nullにセットしてください。 このマクロは、Makefileに特別な依存を含むフラグを挿入したり、特定 のホストやターゲットのためのmakeディレクティブをMakefile に挿入するとき役に立ちます。例えば、configure.inに以下を含ませま す。 AC_SUBST_FILE(host_frag)dnl host_frag=$srcdir/conf/sun4.mh そしてMakefile.inに以下を含ませます。 @host_frag@

Caching Results

様々なconfigureスクリプトで、同じ特徴を繰り返し調べる(あるは何度 も一つのスクリプトを実行する)ことを避けるため、configureは多くの 調査結果をcache fileに保存します。configureスクリプト実行時 にキャッシュファイルを見つけた場合、前の実行結果をそれから読みだし、これ らの再実行を避けます。結果として、configureは毎回調査を実行するよ り早くなります。

AC_CACHE_VAL (cache-id, commands-to-set-it)

Macro

cache-idで識別した調査結果が利用可能だということを保証します。調査 結果が読み込まれたキャッシュファイルにあり、configureに --quietや--silentオプションが与えられていない場合、結果が キャッシュされていることを示すメッセージを出力します。それ以外ではシェル コマンドcommands-to-set-itを実行します。これらのコマンドは設定され た変数cache-id以外に副作用をしません。特に、そこでAC_DEFINE を呼び出すべきではありません。AC_CACHE_VALの呼び出しに続くコード はキャッシュ値に基づきそれを行います。同様に、例えば AC_MSG_CHECKINGのメッセージを出力しません。AC_CACHE_VALを 呼び出す前に行うので、調査結果がキャッシュから得られるかシェルコマンド実 行による定義からかにかかわらず、メッセージは出力されます。シェルコマンド を値を決定するために実行する場合、値はconfigureが出力ファイルを作 る直前に、キャッシュファイルに保存されます。cache-id変数の名前の選 び方は、See Cache Variable Names.

AC_CACHE_CHECK (message, cache-id, commands)

Macro

メッセージ出力に注意が必要なAC_CACHE_VALのラッパーです。このマク ロは、これらのマクロを使う最も普通の方法のための便利な略記法を提供します。 messageのためにAC_MSG_CHECKINGを呼び出すと、cache-id とcommands引数を伴うAC_CACHE_VALと、cache-idを伴う AC_MSG_RESULTを呼び出します。

AC_CACHE_LOAD

Macro

存在するキャッシュファイルから値をロードする、または、キャッシュファイル がない場合、新しいキャッシュファイルを作ります。自動的にAC_INIT から呼び出されます。

AC_CACHE_SAVE

Macro

キャッシュファイルに全てのキャッシュ値を書き込みます。自動的に AC_OUTPUTから呼び出されますが、configure.inのキーポイント でAC_CACHE_SAVEを呼び出すため非常に役に立ちます。すぐにコンフィグ レーションスクリプトが中断する場合、そのようなチェックポイントでキャッシュ してください。

• Cache Variable Names: Shell variables used in caches.
• Cache Files: Files configure uses for caching.

Cache Variable Names

キャッシュ変数名は以下のフォーマットにするべきです:

package-prefix_cv_value-type_specific-value[_additional-options]

たとえば、ac_cv_header_stat_brokenとか、 ac_cv_prog_gcc_traditionalなどのようになります。 変数名の各部分の意味は以下のとおり:

package-prefix

パッケージまたは組織名の略称です; 小文字な点は違いますが、 ローカルに使用しているAutoconfのマクロ名のはじめのprefixと同じです。 Autoconf標準配布に入っているマクロのキャッシュ変数では、 acを使っています。

_cv_

このshell変数がキャッシュであることを示します。

value-type

キャッシュの値の種類です。合理的な名前づけシステムにするためについています。 Autoconfの使う種類名はMacro Namesに挙げられています。

specific-value

このテストが適応するキャッシュ値のクラスのメンバーです。例えば、関数 (alloca)、プログラム(gcc)や、出力変数(INSTALL)です。

additional-options

このテストが適応する特定のメンバーの特定の動作です。例えば、 brokenやsetです。名前のこの部分は適応されない場合は削除さ れます。

キャッシュ変数に割り当てられた値は改行を含めてはいけません。通常、値は真 偽値(yesやno)、あるいはファイルや関数の名前なので、重要な 制限ではありません。

Cache Files

キャッシュファイルは、あるシステム上で実行されたconfigureのテスト結果を 蓄えるshellスクリプトです。これにより、configureスクリプト間、 または複数回のconfigureの実行の間でテスト結果を共有できます。 異なるシステム上ではキャッシュファイルは役にたちません。 もしキャッシュファイルの内容がなんらかの理由で不正になった場合、 ユーザはキャッシュファイルを削除したり編集したりできます。

デフォルトでは、configureは./config.cacheをキャッシュファイルとして 使います。もしなければ新規に作成されます。configureは キャッシュファイルの切替えのため、--cache-file=fileという オプションを受け付けます; configureがサブディレクトリにある configureスクリプトを呼び出す際には、このオプションを使って スクリプト間でキャッシュを共有します。 AC_CONFIG_SUBDIRSマクロを使ってサブディレクトリの設定を する方法については、See Subdirectoriesを参照してください。

--cache-file=/dev/nullとすることで、configureのデバッグのために キャッシュを無効にできます。config.statusは--recheck オプションが指定された場合を除いてキャッシュファイルを参照しません。 config.statusに--recheckには、configureが 再実行されます。デバッグ期間が長くなりそうな場合には、以下のように キャッシュ関連マクロをconfigure.inの先頭で再定義することで、 configureスクリプトがキャッシュ読み込み/書き出しをしないように できます。

define([AC_CACHE_LOAD], )dnl
define([AC_CACHE_SAVE], )dnl
AC_INIT(whatever)
 ... rest of configure.in ...

特定のシステム用のキャッシュファイルを配布しようとするのはよくないことです。 あまりにもエラーが発生しやすく、管理コストがあまりに高すぎます。 自動判別できないOS機能については、正規化されたシステムタイプ名を得て リンクするファイルを選ぶ方法を使いましょう(see Manual Configuration 参照)。この方法は標準化されています。

あるシステム向けのキャッシュファイルは、configureスクリプトを 実行するごとに内容が追加されていきます; 初期状態では空です。 configureを実行すると、configureは新しいテスト結果と キャッシュファイルの内容をマージします。サイト向け初期化スクリプトの中で、 デフォルトで利用されるものでない、サイト単位のキャッシュファイルを 指定することができます。サイト単位のキャッシュファイルは、 同じCコンパイラが利用されている限り、透過的に働きます (see Site Defaults参照)。

configureスクリプトやconfigure.inから呼び出されるマクロがコンフィグレー ションプロセスを中断する場合、数回のキーポイントでのキャッシュのチェック ポイントは役に立ちます。そうすると、(希望通り)以前にエラーを引き起こした 部分を修正したコンフィグレーションスクリプトを再実行する時間を、大幅に削 除します。

 ... AC_INIT, etc. ...
dnl checks for programs
AC_PROG_CC
AC_PROG_GCC_TRADITIONAL
 ... more program checks ...
AC_CACHE_SAVE

dnl checks for libraries
AC_CHECK_LIB(nsl, gethostbyname)
AC_CHECK_LIB(socket, connect)
 ... more lib checks ...
AC_CACHE_SAVE

dnl Might abort...
AM_PATH_GTK(1.0.2, , exit 1)
AM_PATH_GTKMM(0.9.5, , exit 1)

Printing Messages

configureスクリプトは、configureを実行しているユーザに 各種の情報を知らせる必要があります。以下のマクロは各種の状況に適した方法で メッセージを出力します。以下の全てのマクロの引数は、shell用に ダブルクォートで囲まれます。このため、shellは変数とbackquoteの置換を 行います。カンマを含むメッセージは、m4のquote文字である角括弧で メッセージを囲めば出力できます。

AC_MSG_RESULT([never mind, I found the BASIC compiler])

これらのマクロはshellコマンドのechoのwarpperです。 configureスクリプトでは、ほとんどの場合 ユーザにメッセージを出力するのにechoを直接使う必要はありません。 ここで挙げたマクロを使えば、メッセージの出力時期と出力されかたを 簡単に変えることができます。メッセージ出力マクロの定義を変えれば、 全ての呼び出し側マクロの出力を変えられます。

AC_MSG_CHECKING (feature-description)

Macro

configureが、ある特定のOS機能をチェックしていることをユーザに 知らせます。このマクロはchecking ではじまり、...で終る、 改行なしのメッセージを出力します。このマクロの後にはAC_MSG_RESULTを 呼び出し、チェック結果と改行を出力する必要があります。 feature-descriptionはたとえば whether the Fortran compiler accepts C++ commentsとか、 for c89とかがよいでしょう。 このマクロはconfigureが--quietオプション、または --silentオプションつきで実行された場合、なにも出力しません。

AC_MSG_RESULT (result-description)

Macro

ユーザにテスト結果を知らせます。result-descriptionは ほとんど常に、キャッシュ変数の値で、たいていyesかnoか ファイル名になります。このマクロはAC_MSG_CHECKINGに続いて 呼び出される必要があります。また、result-descriptionに 指定するメッセージはAC_MSG_CHECKINGの出力したメッセージを 終結させるさせるものでなければなりません。 このマクロはconfigureが--quietオプション、または --silentオプションつきで実行された場合、なにも出力しません。

AC_MSG_ERROR (error-description)

Macro

ユーザにconfigureが中断してしまうようなエラーに関して知らせます。 このマクロは標準エラー出力にエラーメッセージを出力し、 configureを終了します。exit statusは0でない値になります。 error-descriptionはたとえばinvalid value $HOME for \$HOME などのようなテキストがいいでしょう。

AC_MSG_WARN (problem-description)

Macro

configureのユーザに問題になり得る点を知らせます。 このマクロは標準エラー出力にメッセージを出力します; configureは以後も実行を続けます。 ので、AC_MSG_WARNを呼び出すマクロは、 警告する内容に関して、デフォルトの(代用の)ふるまいを 提供するべきです。problem-descriptionはたとえば ln -s seems to make hard linksのようなテキストがいいでしょう。

以下のふたつのマクロはobsoleteです。 AC_MSG_CHECKINGやAC_MSG_RESULTを使いましょう。

AC_CHECKING (feature-description)

Macro

このマクロはAC_MSG_CHECKINGと似ていますが、AC_CHECKINGは feature-descriptionのあとに改行を出力します。 このマクロは主に、複数並んだOS機能チェックの全体としての目的を 出力するのに使えます。たとえば: AC_CHECKING(if stack overflow is detectable)

AC_VERBOSE (result-description)

Macro

このマクロはAC_MSG_RESULTと似ています。 ただし、AC_VERBOSEはAC_MSG_CHECKINGではなく、 AC_CHECKINGに続いて呼び出される、という点だけが違います。 メッセージはtabに続いて出力されます。 このマクロはobsoleteです。

Writing Macros

複数のソフトウェアパッケージに適用できるOS機能のテストマクロを記述 する場合、新しいマクロとして定義するのが最もよい方法です。 以下ではAutoconfマクロを記述するための手順とガイドラインを示します。

• Macro Definitions: Basic format of an Autoconf macro.
• Macro Names: What to call your new macros.
• Quoting: Protecting macros from unwanted expansion.
• Dependencies Between Macros: What to do when macros depend on other macros.

Macro Definitions

AutoconfのマクロはAC_DEFUNマクロを使って定義されます。 これはm4のdefineマクロと類似しています。 AC_DEFUNはマクロを定義する際に、マクロの呼び出し順を 制約するためのコードを加えます(see Prerequisite Macros参照)。

Autoconfマクロの定義は以下のようになります:

AC_DEFUN(macro-name, [macro-body])

角括弧はオプショナルという意味ではありません; 角括弧はマクロ展開の 問題を避けるため、実際に字面の上でもマクロ定義に記述される必要があります (see Quoting参照)。マクロに渡される引数は、$1や$2として 参照できます。

m4プログラム内にコメントを記述するためには、m4組み込みの dnlを使ってください; これはm4に次の改行までのテキストを 無視させます。acsite.m4とaclocal.m4の中のマクロ定義の間には dnlは必要ありません。AC_INITが呼び出されるまでの出力は 無視されるからです。

m4マクロを書く詳細は、See Definitions.

Macro Names

Autoconfマクロの名前は、他の文字列との衝突を避けるため、 全て大文字で、AC_で始まっています。内部で使われるshell変数は なるべく全部小文字で、ac_で始まっています。 既存の/将来のAutoconfマクロと衝突しないために、 自分で定義するマクロの名前およびshell変数の名前には、 先頭に別の文字列を使うべきです。例えばあなたのイニシャル、組織名や ソフトウェアパッケージの名前の略称などが考えられます。

Autoconfマクロの名前は、ほとんどの場合構造化された名前づけ規則に したがっています。名前はチェックされるOSの機能を示しています。 マクロ名は下線で区切られたいくつかの単語からなり、各単語は 一般的なものから特殊なものへと並んでいます。マクロに対する キャッシュ変数の名前もおなじ規則を使っています(より詳しくは see Cache Variable Names参照)。

AC_の次にある単語は、調べる対象のOS機能のカテゴリを示しています。 ここに、書く可能性の高いマクロの種類のテストマクロを指定するため、 Autoconfが使うカテゴリがあります。それらはキャッシュ変数でも全て小文字で 使われます。適用可能なものを使ってください。無ければ独自のカテゴリを考え 出してください。

C

C言語組み込みの特徴。

DECL

ヘッダファイルでのC変数の宣言。

FUNC

ライブラリの関数。

GROUP

ファイルのUNIXグループオーナー。

HEADER

ヘッダファイル。

LIB

Cライブラリ。

PATH

プログラムを含むファイルのフルパス名。

PROG

プログラムのベース名。

STRUCT

ヘッダファイルのC構造体の定義。

SYS

OSの特徴。

TYPE

C組み込みや宣言タイプ。

VAR

ライブラリのC変数。

カテゴリ名の次には、テスト対象のOS機能の名前が来ます。 それ以降の単語はそれぞれOSの機能の持つ特定の意味を表しています。 例えば、AC_FUNC_UTIME_NULLはutime関数の引数に NULLを与えたときのふるまいをチェックします。

あるマクロの内部サブルーチンとして動作するマクロには、 呼び元マクロ名のあとに、マクロが行うことがらを意味する ひとつ以上の単語をつけた名前をつけるのがよいです。 たとえば、AC_PATH_XはAC_PATH_X_XMKMFと AC_PATH_X_DIRECTを内部で呼び出すマクロとして使います。

Quoting

他のマクロに呼び出されるマクロはm4によって複数回評価されます; 通常の文字列がマクロやm4組み込み命令(たとえばdefineや $1)と勘違いされて評価されないように、各評価ごとにもう1重 quoteする必要があるかもしれません。また、カンマを含むマクロの 引数についてはquoteする必要があります。なぜなら、カンマは各引数を 区切るのに使われるからです。改行を含むマクロの引数を与える場合や、 他のマクロを呼び出す場合にはquoteする方がいいでしょう。

Autoconfは、m4のquote文字を、デフォルトの`と'から [と]に変更しています。これは多くのマクロで `と'は対応せずに使われているからです。しかしながら、 ときどき角カッコをマクロ内で使用する必要が出る場合があります (Cプログラムソースや正規表現など)。そのような場合、m4の 組み込み命令changequoteを使って一時的にquote文字を<<と >>に切替えます(quoteを全く必要としない場合、quote文字に空文字を 指定することでquoteの機能を殺すこともできます)。 以下、例題です:

AC_TRY_LINK(
changequote(<<, >>)dnl
<<#include <time.h>
#ifndef tzname /* For SGI.  */
extern char *tzname[]; /* RS6000 and others reject char **tzname.  */
#endif>>,
changequote([, ])dnl
[atoi(*tzname);], ac_cv_var_tzname=yes, ac_cv_var_tzname=no)

configureを新しく書いたマクロを使って生成する場合、 マクロ内にquoteを増やす必要があるかないか注意深く確認しましょう。 もしひとつ異常の単語がm4の出力から落ちていたら、 quoteする必要があります。疑わしいときはとりあえずquoteしましょう。

しかし、quoteしすぎてしまう場合もあります。このような場合、 出力されたconfigureスクリプトは展開されないままのマクロを 含んでいます。autoconfはこのような場合を検出するために、内部で grep AC_ configureを実行します。

Dependencies Between Macros

Autoconfマクロの一部は、正常な動作のために他のマクロが先に呼ばれていることを 仮定しています。Autoconfは特定のマクロを必要な場合にだけ呼び出したり、 正常に動作しない可能性のある順でマクロが呼び出された場合に 警告したりする方法を提供しています。

• Prerequisite Macros: Ensuring required information.
• Suggested Ordering: Warning about possible ordering problems.
• Obsolete Macros: Warning about old ways of doing things.

Prerequisite Macros

一部のマクロは、他のマクロで求められた値を必要とすることがあります。 例えば、AC_DECL_YYTEXTはflexやlexの出力 結果を調べます。このため、shell変数LEXを設定するために AC_PROG_LEXマクロが先に呼ばれている必要があります。

AC_REQUIREマクロを使う事で、ユーザにマクロ間の依存関係を 管理させずに済みます。つまり、自動化できます。AC_REQUIREを 使うと、あるマクロを必要な場合にだけ、かつ1度だけ呼び出すことができます。

AC_REQUIRE (macro-name)

Macro

もしmacro-nameという名前のm4マクロが まだ呼び出されていなかったら、そのマクロを (引数なしで)呼び出します。macro-nameを 角カッコでquoteするのを忘れないでください。 macro-nameに指定されるマクロは AC_DEFUNで前もって定義されているか、 AC_PROVIDEの呼び出しを含んでいるかする 必要があります。これはmacro-nameが 呼び出されたことを検出するため必要です。

AC_DEFUNを使うかわりに、defineを使ってマクロを定義し、 中でAC_PROVIDEを呼び出すこともできます。この技法は メッセージのネストを防ぐ事ができないので、obsoleteです。

AC_PROVIDE (this-macro-name)

Macro

マクロthis-macro-nameが呼び出されたことを 記録します。this-macro-nameはAC_PROVIDE マクロを呼び出すマクロの名前でなければなりません m4の組み込み変数$0を使うと簡単に マクロの名前を得る事ができます。たとえばこんな風: AC_PROVIDE([$0])

Suggested Ordering

あるふたつのマクロについて、両方が呼び出される場合には片方が先に 呼び出されなければならないが、どちらも他方が呼び出されることを 必須としない場合があります。たとえば、Cコンパイラのふるまいを 変えるマクロはCコンパイラを呼び出すマクロ以前に呼び出される 必要があります。このような依存関係の多くはこの文書に記されています。

Autoconfはこのような場合のためにAC_BEFOREマクロを提供しています。 これは、依存関係があるマクロがconfigure.in中に逆順で現れた 場合に、ユーザに警告します。警告メッセージはconfigureを実行する ときではなく、configure.inからconfigureを生成するときに 出力されます。 例えば、AC_PROG_CPPマクロは、Cコンパイラに-E オプションをつけたときにCプリプロセッサを実行してくれるかを 調べます。このため、このマクロは利用されるCコンパイラを変更するような マクロ、たとえばAC_PROG_CCなどより後に呼び出される必要があります。 このため、AC_PROG_CCは以下の文を含んでいます:

AC_BEFORE([$0], [AC_PROG_CPP])dnl

この文を使うと、AC_PROG_CCが呼ばれた時点でAC_PROG_CPPが 既に呼ばれていた場合、ユーザに警告がでます。

AC_BEFORE (this-macro-name, called-macro-name)

Macro

マクロcalled-macro-nameが既に呼び出されていた 場合、m4が標準エラー出力に警告メッセージを 出力するようにします。this-macro-nameは マクロAC_BEFOREを呼び出すマクロの名前である 必要があります。called-macro-nameに 指定されるマクロはAC_DEFUNで前もって 定義されているか、AC_PROVIDEの呼び出しを 含んでいるかする必要があります。これは called-macro-nameが呼び出されたことを 検出するため必要です。

Obsolete Macros

自動設定および移植性向上のための技法は数年かけて徐々に進化しています。 しばしば、ある問題を解決するためのよりよい方法が開発されたり、 やっつけ仕事が系統だてて整理されたりします。このような変化は Autoconfの多くの部分で置きました。この結果、一部のマクロは obsoleteとされるようになりました; それらのマクロは 動作はしますが、最適なやりかたではなくなりました。 AutoconfはAC_OBSOLETEマクロを用意しています。 このマクロは、configureスクリプトを作っているユーザが obsoleteなマクロを使用した場合に警告し、あたらしいマクロに 移行するよう勧めます。使用例はこんなかんじ:

AC_OBSOLETE([$0], [; use AC_CHECK_HEADERS(unistd.h) instead])dnl

AC_OBSOLETE (this-macro-name [, suggestion])

Macro

m4から標準エラー出力へ、マクロ this-macro-nameはobsoleteだ、という メッセージを出力させます。また、マクロが 使用されたファイル名と行番号も 出力されます。this-macro-nameは AC_OBSOLETEを呼び出しているマクロの 名前である必要があります。もしsuggestionが 指定されていたら、警告メッセージの末尾に 指定された文字列が出力されます; 例えば、this-macro-nameのかわりに 使うべきマクロ名などがいいでしょう。

Manual Configuration

一部のOS機能は、テストプログラムを実行しても自動的に判定できません。 たとえば、オブジェクトファイルのフォーマットや、コンパイラや リンカに渡さねばならない特殊なオプションなどがそうです。 unameの出力結果を調べたり、特定のシステムにしかない ライブラリを調べるなどのアドホックな手段を使って、 このようなOSの機能をチェックすることができます。 Autoconfは推測することのできないOS機能の判定のために、 統一された方法を提供しています。

• Specifying Names: Specifying the system type.
• Canonicalizing: Getting the canonical system type.
• System Type Variables: Variables containing the system type.
• Using System Type: What to do with the system type.

Specifying the System Type

他のGNU configureスクリプトと同様、 Autoconfによって生成されたconfigure スクリプトは正規化されたシステムタイプ名によって 動作を決定することができます。 システムタイプ名は以下のフォーマットになっています:

cpu-company-system

configureは通常、configureの動作している システムタイプ名を判定することができます。このために、 configureはconfig.guessというスクリプトを実行します。 このスクリプトはunameコマンドや、Cプリプロセッサが あらかじめ定義しているシンボルを使ってシステムタイプ名を 割り出します。

あるいは、ユーザはconfigureのコマンドライン引数に システムタイプ名を指定することができます。 クロスコンパイル時にはこれは必ず必要です。 最も複雑な場合、3つのシステムタイプ名が関係します。 これらを指定するためのオプションは以下のとおり:

--build=build-type

パッケージを自動設定し、コンパイルするマシンのシステムタイプ名 (ほとんどの場合必要ないです);

--host=host-type

パッケージが実行されるシステムタイプ名;

--target=target-type

パッケージ中のコンパイラ関連ツールがコード生成を行う場合、 生成するコード種別のシステムタイプ名。

ユーザが(オプション名なしで)システムタイプ名をconfigureの 引数として与えた場合、その値がhost/target/buildのシステムタイプ名の デフォルト値として使われます。--buildなどのオプションを指定 しなかった場合、この値が使われます。targetとbuildのシステムタイプ名は、 targetまたはbuildを指定せずにhostを指定した場合、 hostのシステムタイプ名と同一になります。 クロスコンパイルを行う場合、クロスコンパイル用ツール、特にCコンパイラの 名前を、configureのコマンドラインに指定する必要があります。 たとえば以下のように:

CC=m68k-coff-gcc configure --target=m68k-coff

configureは多くのシステムタイプについて、短い別名も認識します。 たとえば、decstationをmips-dec-ultrix4.2のかわりに コマンドラインに指定することができます。configureは システムタイプ名の正規化のため、config.subというスクリプトを 実行します。

Getting the Canonical System Type

以下のマクロを使うと、configureスクリプトの中でシステムタイプを 知ることができます。これらのマクロはconfig.guessというshell スクリプトを実行します。これにより、ユーザが指定しなかった、host/ target/buildシステムタイプ名などの情報を得ます。また、config.subを 実行することでユーザの指定したシステムタイプの別名を正規化します。 以下のマクロを利用する場合、これら2つのshellスクリプトをソースコードと ともに配布する必要があります。configureがこれらの スクリプトを探すディレクトリを指定するためのマクロ、 AC_CONFIG_AUX_DIRについてはSee Output参照。 以下のマクロを利用しなかった場合、configureは 指定された--host、--targetおよび--buildの オプションを無視します。

AC_CANONICAL_SYSTEM

Macro

システムタイプを判定し、正規化されたシステムタイプ名を 出力変数に設定します。設定される変数については See System Type Variablesを参照。

AC_CANONICAL_HOST

Macro

AC_CANONICAL_SYSTEMの一部、ホストタイプに関する 部分だけを実行します。プログラムがコンパイラ関連の ツールでなければ、このマクロのやることだけでことが足ります。

AC_VALIDATE_CACHED_SYSTEM_TUPLE (cmd)

Macro

キャッシュファイルが、現在のホスト、ターゲットとビルドシステムに一致しな い場合、cmdを実行する、または、デフォルトエラーメッセージを出力し ます。

System Type Variables

AC_CANONICAL_SYSTEMを呼び出すと、以下の出力変数に システムタイプの情報が設定されます。AC_CANONICAL_HOSTの 実行語は、変数hostだけが設定されます。

build, host, target

正規化されたシステム名;

build_alias, host_alias, target_alias

ユーザが指定したシステム名、またはconfig.guessが 使われた場合には正規化されたシステム名;

build_cpu, build_vendor, build_os

host_cpu, host_vendor, host_os

target_cpu, target_vendor, target_os

正規化された名前の特定の部分だけが(便利のために)設定されます。

Using the System Type

正規化されたシステムタイプをどう使いますか? たいていは、システム依存の Cファイルを選択するために、configure.inの中のひとつまたは 複数のcase文で使います。そのようなファイルにはシステム名を もとにした名前をつけておきます。その後、 host.hやtarget.cなどの汎用的な名前で そのファイルへの(シンボリック)リンクを作ります。 case文のパターンには以下のように、shellのワイルドカードが使えます。 ので、複数の場合をまとめて扱えます:

case "$target" in
i386-*-mach* | i386-*-gnu*) obj_format=aout emulation=mach bfd_gas=yes ;;
i960-*-bout) obj_format=bout ;;
esac

AC_LINK_FILES (source..., dest...)

Macro

AC_OUTPUTの際に、既存のファイルsourceに対する destという名前のリンクを作ります。リンクの種類は可能なら シンボリックリンク、さもなくばハードリンクになります。 destとsourceに指定されるファイル名は ソースコードのトップレベルから、またはビルドディレクトリからの 相対表記でなければなりません。 このマクロは複数回呼んでも構いません。 例えば、以下を使うと: AC_LINK_FILES(config/${machine}.h config/${obj_format}.h, host.h object.h) 現在のディレクトリにhost.hという srcdir/config/${machine}.hへのリンクと、 object.hというsrcdir/config/${obj_format}.hへの リンクを作成します。

ホストのシステムタイプを使って、クロスコンパイル用のツールを みつけることができます。AC_CHECK_TOOLマクロがそのために する内容については、See Generic Programs参照。

Site Configuration

configureスクリプトでは、パッケージがインストールされる場面ごとに 設定の一部を変えるための機能を備えています(訳註: 意訳)。 外部プログラムパッケージの置かれている場所を指定したり、 オプションの機能を含めたり外したり、プログラムを デフォルトの名前以外でインストールしたり、 configureのオプションの既定値を定めたりするための方法が 用意されています。

• External Software: Working with other optional software.
• Package Options: Selecting optional features.
• Site Details: Configuring site details.
• Transforming Names: Changing program names when installing.
• Site Defaults: Giving configure local defaults.

Working With External Software

ソフトウェアパッケージが他のソフトウェアパッケージを必要としたり、 あるいは特定の場合だけ利用したりすることがあります。 ユーザはconfigureを呼び出す際のコマンドラインオプションにより、 どのソフトウェアパッケージを利用するかを指定できます。 オプションは以下のいずれかの形式をしています:

--with-package[=arg]
--without-package

例えば、--with-gnu-ldは他のリンカでなく、GNUリンカを 利用することを指示します。 --with-xはX Window Systemを利用することを指示します。

ユーザは、パッケージ名の後に=に続いて引数を渡すことができます。 パッケージ名の後ろにnoを与えると、デフォルトで利用される パッケージを利用させなくすることがえきます。 yesでもnoでもない引数は、 より細かく外部パッケージを指定するため、 外部パッケージのパッケージ名やバージョン番号を指定するのに使えるでしょう。 引数が与えられなかった場合、yesが与えられたのとおなじことになります。 --without-packageは --with-package=noとおなじです。

configureスクリプトは、サポートされていないパッケージについて --with-packageが指定されてもエラーを出しません。 複数のソフトウェアパッケージをトップレベルのconfigure スクリプトでまとめて設定する場合のためにこのような動作になっています。 これにより、各ソフトウェアパッケージが異なるオプションを要求している場合でも、 余計なエラー出力なしで設定できます。 残念な副作用として、オプションの綴ミスはチェックされません。

configureスクリプトを 呼び出したユーザがどんなオプションを指定したか知るためには、 各外部ソフトウェアパッケージについて、 configure.in中でAC_ARG_WITHを呼び出す必要があります。 各パッケージがデフォルトで利用されるかされないか、またどんな引数が有効かは configure.inを書くあなたまかせです。

AC_ARG_WITH (package, help-string [, action-if-given [, action-if-not-given]])

Macro

configureスクリプトにユーザが --with-packageや --without-packageのような コマンドラインオプションを与えた場合、 shellコマンドaction-if-givenを実行します。 もしどちらも与えられなかった場合、 action-if-not-givenを実行します。 packageは外部ソフトウェアパッケージの名前を示します。 packageは英数字とマイナス記号だけでできている必要があります。 コマンドラインオプションの引数は、 shellコマンドaction-if-givenの中から shell変数withvalとして参照できます。 withvalの値はshell変数with_package (パッケージ名中の-は_に変換されます)の 値とおなじですので、どちらを使っても構いません。 help-stringはオプションの概説です。 例えば以下のようにします: --with-readline support fancy command line editing help-stringは必要なら2行以上にわたっても構いません。 configure --helpを実行したとき、桁が揃うようにしてください。 help-string中にはtab文字は使わないでください。 行の先頭にスペースを含めるためには、[と]でくくる 必要があるでしょう。

AC_WITH (package, action-if-given [, action-if-not-given])

Macro

これは、AC_ARG_WITHの古いバージョンです。 help-stringが使えません。

Choosing Package Options

ソフトウェアパッケージに コンパイル時に使うかどうか選べる機能拡張がある場合、 ユーザはconfigureのコマンドラインにオプションを指定することで 有効/無効を切り替えられます。 このオプションは以下の形式をとります:

--enable-feature[=arg]
--disable-feature

このオプションを使えば、 ユーザはコンパイル/インストールする機能拡張を選べます。 --enable-featureは、パッケージのある機能のふるまいを変えたり、 機能をさしかえたりするのに使ってはいけません。 プログラムの一部をコンパイルするかしないか選択するためだけに使うべきです。

ユーザは機能名の後に、=に続けて引数を記述できます。 引数にnoをつけると、その機能は「コンパイルされません」。 引数つきのオプションは例えば「--enable-debug=stabs」みたいになります。 引数がついていない場合、引数yesがつけられたのと同等になります。 --disable-featureは--enable-feature=noと同等です。

configureスクリプトは、 サポートしていない--enable-featureオプションが指定されても エラーを出しません。 この機能は複数のパッケージを含むソースコードツリーの設定をするとき便利です。 各パッケージがサポートするオプションが違っていても、 トップレベルのconfigureを呼び出すだけで (オプションに関するエラーメッセージなしで) 全パッケージの設定ができます(訳註: このへん意訳)。 不幸な副作用としては、オプションの綴ミスをしても警告がでません。 この問題に関して、いまのところよりよい方法は提案されていません。

各オプションについて、 configure.inでマクロAC_ARG_ENABLEを呼び出し、 各オプションが指定されたかどうか調べねばなりません。 各オプションがデフォルトで有効/無効かどうか、 どんな引数が有効かはconfigure.inの作者の自由です。

AC_ARG_ENABLE (feature, help-string [, action-if-given [, action-if-not-given]])

Macro

ユーザがconfigureの引数に --enable-featureまたは--disable-featureの オプションを指定した場合、 shellコマンドaction-if-givenを実行します。 どちらも指定されていなければaction-if-not-givenを実行します。 featureはパッケージの機能名です。 featureは英数字とハイフンの組み合わせでないといけません。 action-if-givenの中では、 オプションに=に続き引数が指定されていたら、 shell変数enablevalに値が格納されています。 実際には、enablevalとenable_featureと同じ値になっています (enable_featureのfeature部分は、もとのfeatureの ハイフンを下線(_)にしたもの)。 必要ならどちらを参照しても構いません。 help-stringはAC_ARG_WITH(see External Software)で使われる help-stringと同じです。

AC_ENABLE (feature, action-if-given [, action-if-not-given])

Macro

このマクロはobsoleteです。 AC_ARG_ENABLEからhelp-stringのサポートを外したようなものです。

Configuring Site Details

一部のソフトウェアパッケージは、インストールするサイト依存の情報を 必要とします。 例えば、ある種のサービスにはホスト名が必要です。 コンタクト先として会社名やemailアドレスを使うこともあります。 Metaconfigで生成された設定スクリプトは対話的にこのような情報を 問い合わせます。 Autoconfで生成された設定スクリプトは対話的ではないので、 Autoconfで生成された設定スクリプトではどうやればいいのだろう、と思うでしょう。

このようなサイト依存の設定情報は、プログラムが編集したものではなく、 ユーザだけによって編集されたファイルに格納されている必要があります。 ファイルを置く位置はprefix変数をもとにしたパス、または ユーザのホームディレクトリなどの標準的な場所にします。 ファイルを置く位置を環境変数で設定してもよいでしょう。 プログラムはコンパイル時でなく実行時に、そのファイルを調べます。 実行時の設定はユーザにとってより便利で、設定時に情報を取得するよりも設定 の過程がより単純です。データファイルを置く場所についてのより多くの情報の ために See Directory Variablesを参照してください。

Transforming Program Names When Installing

Autoconfはプログラムをインストールするときにそれらの名前の変更をサポート します。これらの変換を使うにはconfigure.inがマクロ AC_ARG_PROGRAMを呼ばなければなりません。

AC_ARG_PROGRAM

Macro

出力変数program_transform_nameの中にインストールされるプログラム の名前を変更するためのsedコマンドを置きます。 もし後述するオプションのいくつかがconfigureに与えられれば、プログ ラムの名前はそれに応じて変換されます。そうでなければ、もし AC_CANONICAL_SYSTEMが呼ばれるか、--targetの値がホストタイ プ(--hostで指定されるかconfig.subによってデフォルト設定さ れます) と違っていれば、ダッシュが後に続いたターゲットタイプ名を前置詞と して使います。そうでなければプログラム名は変換されません。

• Transformation Options: configure options to transform names.
• Transformation Examples: Sample uses of transforming names.
• Transformation Rules: Makefile uses of transforming names.

Transformation Options

以下のコマンドラインオプションをconfigureに渡すことによって名前の 変換を指定することができます。

--program-prefix=prefix

(プログラムの)名前の前にprefixを付けます。

--program-suffix=suffix

(プログラムの)名前の後にsuffixを付けます。

--program-transform-name=expression

(プログラムの)名前に対してsedの置換演算expressionを行います。

Transformation Examples

これらの変換はクロスコンパイル開発環境の一部になり得るプログラムで役に立 ちます。例えば、Sun 4で--target=i960-vxworksつきでconfigureされた クロスアセンブラは、Sun 4のnativeアセンブラと混同され得るas より もむしろi960-vxworks-as として普通インストールされます。

あなたのシステムにインストールされたGNUプログラムが同じ名前を持った他の プログラムを隠したくないならあなたはプログラムの名前をg付きで始め るように強制できます。例えば、あなたがGNU diffを --program-prefix=g つきでconfigureするなら、あなたがmake installを実行するときにそれは/usr/local/bin/gdiffとしてインストー ルされます。

より洗練された例として、あなたはすでにgがついたgdbやGNUプ ログラムではないless、lesskeyを除いて、ソースツリーにある プログラム名のほとんどにgを付けるように

--program-transform-name='s/^/g/; s/^gg/g/; s/^gless/less/'

を使うことができます。(この特徴を使うため、セットアップされたプログラム を含むソースツリーを持っていることが前提です。)

あるプログラムの複数のバージョンを同時にインストールする1つの方法は、(プ ログラムの)一方または両方の名前にバージョン番号を付けることです。例えば、 あなたがAutoconfバージョン1をちょっとの間保持したいなら、あなたは /usr/local/bin/autoconf2や/usr/local/bin/autoheader2などを インストールするためにAutoconfバージョン2を--program-suffix=2を使っ てconfigureすることができます。

Transformation Rules

これはMakefile.inの中で変数program_transform_nameを使う方 法です。

transform=@program_transform_name@
install: all
        $(INSTALL_PROGRAM) myprog $(bindir)/`echo myprog|sed '$(transform)'`

uninstall:
        rm -f $(bindir)/`echo myprog|sed '$(transform)'`

もしインストールするプログラムが1つ以上あるなら、あなたはループの中でそ れを行います。

PROGRAMS=cp ls rm
install:
        for p in $(PROGRAMS); do \
          $(INSTALL_PROGRAM) $$p $(bindir)/`echo $$p|sed '$(transform)'`; \
        done

uninstall:
        for p in $(PROGRAMS); do \
          rm -f $(bindir)/`echo $$p|sed '$(transform)'`; \
        done

ドキュメントファイル(Texinfoやman)に対して(名前の)変換を行うかど うかは、手の込んだ疑問(tricky question)です。名前変換に関するいくつかの 理由のために完全な回答はなさそうです。ドキュメントは、特定のアーキテクチャ に対して普通特別ではありません。そしてTexinfoファイルはシステムドキュメ ントと衝突しません。しかしそれらは同じファイルの以前のバージョンと衝突す るかも知れませんし、manページはときどきシステムドキュメントと衝突 します。折衷案として、おそらく最も良いのはmanに対しては名前変換を 行い、Texinfoマニュアルには行わないことです。

Setting Site Defaults

Autoconfが生成するconfigureスクリプトは何らかの設定値のためにあな たのサイトにデフォルト値を与えることを許します。あなたはサイトやシステム 全体の初期化ファイルを作ることでこれを行います。

もし環境変数CONFIG_SITEが設定されていれば、configureはその 値を読み込むシェルスクリプトの名前として使用します。そうでなければシェル スクリプトprefix/share/config.siteをそれが存在すれば読み込 み、prefix/etc/config.siteをそれが存在すれば読み込みます。 したがって、マシン特有のファイルの設定がマシン独自の設定に、それが衝突す る場合置き換わります。

サイトファイルは恣意的なシェルスクリプトであり得ますが、 but only certain kinds of code are really appropriate to be in them.configureは サイトファイルを読んだ後でキャッシュファイルを読むので、 サイトファイルは、 そのシステムで実行されるconfigureスクリプトのすべてで共有されるデ フォルトのキャッシュファイルを定義することができます。もしサイトファイル でデフォルトキャッシュファイルを設定するならそのサイトファイルの中で出力変数 CCも設定するのは良い考えです。なぜなら、キャッシュファイルは特定 のコンパイラに対してだけ正当であるのに、多くのシステムはいくつかの(訳註: コンパイラを？)使うことができるからです。

あなたはサイトファイルの中でconfigureコマンドラインオプションで設 定された値を検査したり上書きしたりできます。オプションはそのオプションと 同じ名前を持つシェル変数をダッシュをアンダースコアに変えて設定します。例 外は、--without-と--disable-オプションは対応する --with-や--enable-オプションとその値noを与えること と同じであることです。したがって、--cache-file=localcacheは変数 cache_fileに値localcacheを設定します。 --enable-warnings=no や--disable-warningsは変数 enable_warningsに値noを設定します。--prefix=/usrは 変数prefixに値/usrを設定します。などなど。

サイトファイルはCFLAGSのような他の出力変数のためのデフォルト値を 設定する良い場所でもあります。あなたが普段、繰り返しコマンドラインで行っ ている何らかのノンデフォルト値を与えることを必要とするならば。もしあなた がprefixやexec_prefix(wherever you locate the site file)にノ ンデフォルト値を使うなら、あなたはそれらをサイトファイルに設定することが できます if you specify it with the CONFIG_SITE environment variable.

あなたはいくつかのキャッシュ変数をサイトファイル自身の中で設定することが できます。これを行うことはあなたがクロスコンパイルを行うならば役に立ちま す。テストプログラムの実行に必要な特徴を検査するのは不可能なので。 prefix/etc/config.siteにそのシステムのために正しく値を設定 することによってあなたは"キャッシュを装填"することができます。あなたが 設定することを必要とするキャッシュ変数の名前を見つけるにはaffected configureスクリプトやそのマクロのためのAutoconf m4 ソース コードの中にある、名前に_cv_が付いたシェル変数を探します。

キャッシュファイルはサイトファイルの中で設定する変数を上書きしないように 注意しています。同様に、サイトファイルの中にあるコマンドラインオプション を上書きするべきではありません。あなたのコードはprefixや cache_fileのような変数がそれらのデフォルト値(configureの上 位付近にある)を持つようにそれを変更する前に検査するべきです。

ここにサンプルファイル/usr/share/local/gnu/share/config.siteがあ ります。コマンドconfigure --prefix=/usr/share/local/gnuはこのファ イルを読み込みます(もしCONFIG_SITEが違うファイルに設定されてなけ れば)。

# config.site for configure
#
# Change some defaults.
test "$prefix" = NONE && prefix=/usr/share/local/gnu
test "$exec_prefix" = NONE && exec_prefix=/usr/local/gnu
test "$sharedstatedir" = '${prefix}/com' && sharedstatedir=/var
test "$localstatedir" = '${prefix}/var' && localstatedir=/var
#
# Give Autoconf 2.x generated configure scripts a shared default
# cache file for feature test results, architecture-specific.
if test "$cache_file" = ./config.cache; then
  cache_file="$prefix/var/config.cache"
  # A cache file is only valid for one C compiler.
  CC=gcc
fi

Running configure Scripts

以下では、configureスクリプトを使ったパッケージをどうやって 自動設定するかを述べます。以下のテキストは、パッケージに添付する INSTALLファイルとしても使えます。配布可能なプレーンテキスト版の INSTALLはAutoconfパッケージに含まれています。

• Basic Installation: Instructions for typical cases.
• Compilers and Options: Selecting compilers and optimization.
• Multiple Architectures: Compiling for multiple architectures at once.
• Installation Names: Installing in different directories.
• Optional Features: Selecting optional features.
• System Type: Specifying the system type.
• Sharing Defaults: Setting site-wide defaults for configure.
• Operation Controls: Changing how configure runs.

基本インストール

これらは一般的なインストール説明書です。

configureシェルスクリプトは、コンパイル時に利用する、様々なシステ ム依存変数の、正しい値を推測します。パッケージの、それぞれのディレクトリ のMakefileを作るために、これらの値は使われます。システム依存の定 義を含む、一つ以上の.hファイルも作ります。最終的に、将来、現在の コンフィグレーションを再生成する、シェルスクリプト config.status と、再コンフィグレーションのスピードをあげるため、テストの結果を保存する ファイルconfig.cacheと、コンパイラ出力を含むファイル config.log(主にconfigureのデバッグで役立ちます)を作ります。

パッケージをコンパイルするため、通常でないことをする必要がある場合、そう するためにconfigureにチェックさせた方法を理解し、次のリリースに反 映できるように、READMEにあるアドレスに、diffの結果や説明をメール してください。いくつかの点で、保存する必要のないconfig.cacheの結 果は、削除したり編集したりして構いません。

ファイルconfigure.inは、autoconfと呼ばれるプログラムで、 configureを作るために使われます。変更したり、新しいバージョンの autoconfで再生成したい場合だけ、configure.inが必要です。

このパッケージをコンパイルする最も単純な方法は、以下の通りです。

1. パッケージのソースを含むディレクトリにcdして、システムに対するパッ ケージのコンフィグレーションのため、./configureと入力してください。 System Vの古いバージョンのcshを使っている場合、 cshで configureを実行させないため、sh ./configureと入力する必要 がある可能性があります。

   configureの実行には、しばらくかかります。実行中、調べている特徴を 伝えるメッセージを出力します。

2. パッケージをコンパイルするためにmakeと入力してください。
3. オプションとして、パッケージ付属の自己テストを実行するため、make checkと入力してください。
4. プログラムと、あらゆるデータファイルと、ドキュメントをインストールするた め、make installと入力してください。
5. ソースコードディレクトリから、プログラムバイナリやオブジェクトファイルを 削除することは、make cleanでできます。configureが作ったファ イルの削除(他の種類のコンピュータに対するパッケージの、コンパイルできる ようにするため)は、make distcleanの入力で可能です。 make maintainer-cleanターゲットもありますが、主にパッケージ開発者用です。そ れを使う場合、配布物の付属ファイルを再生成するため、他のプログラムを使う 必要が発生するかも知れません。

コンパイラとオプション

configureスクリプトが知らない、普通使わない、コンパイルやリンクの オプションが必要なシステムもあります。環境変数に初期値をセットすることで、 configureにそれを与えることができます。Bourneシェル互換のシェルを 使って、以下のようにコマンドラインで行うことができます。

CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure

envプログラムがあるシステムでは、以下のようにしてもできます。

env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure

複数のアーキテクチャに対するコンパイル

それぞれのアーキテクチャのためのオブジェクトファイルを、それ自身のディレ クトリに置くことで、同時に1種類以上のコンピュータで、パッケージをコンパ イルすることができます。こうするために、GNU makeの様に、 VPATH変数をサポートするmakeのバージョンを使う必要がありま す。オブジェクトファイルと実行可能なファイルを置くディレクトリに cdして、configureスクリプトを実行します。 configure は、configureがあるディレクトリと..で、ソースコードを自動 的に調べます。

VPATHをサポートしないmakeを使う必要がある場合、ソースコー ドディレクトリで、一度、一つのアーキテクチャのために、パッケージをコンパ イルする必要があります。一つのアーキテクチャのパッケージをインストールし た後、他のアーキテクチャに対して再コンフィグレーションするため、 make distcleanを使ってください。

インストール名

デフォルトで、make installはパッケージファイルを、 /usr/local/binや/usr/local/man等にインストールします。イン ストールプレフィクスを、--prefix=pathオプションで configureに与えることで、特定することができます。

アーキテクチャ特有のファイルと、アーキテクチャ非依存のファイルを、別々の インストールプレフィクスに分けて特定することができます。 configureに--exec-prefix=pathオプションを与えた場合、 パッケージは、プログラムとライブラリをインストールするプレフィクスとして、 pathを使います。ドキュメントと他のデータファイルは通常のプレフィク スを使います。

さらに、普通でないディレクトリ配置を使う場合、特定の種類のファイルに対し、 異なる値で特定するよう、--bindir=pathのようなオプションを与 えることで可能です。セットできるディレクトリリストと、そこに置きたいファ イルの種類は、configure --helpで見ることができます。

パッケージがサポートする場合、configureに --program-prefix=PREFIXや --program-suffix=SUFFIXオプションを与えることで、プログラム を、追加のプレフィクスやサフィックスで、インストールすることができます。

オプションの特徴

configureへの--enable-featureオプションに注意を払う パッケージもあり、featureは、パッケージのオプションパートを示しま す。--with-packageオプションに注意を払うパッケージもあり、 packageは、gnu-asやx(X Window System用)の様なもので す。READMEは、パッケージが理解する、 --enable-と --with-オプションに付いて述べています。

X Window Systemを使うパッケージのため、configureは普通、Xインクルー ドやリンクファイルを自動的に見つけますが、できなかった場合は、 configureオプションの、--x-includes=dirと --x-libraries=dirを、場所を特定するために使うことができます。

システムタイプの指定

configureが自動的に判定できない特徴もありますが、パッケージを実行 する、ホストのタイプを定義する必要があるものもあります。普通 configureはそれを判定できますが、ホストタイプが分からない旨メッセー ジを出力した場合、--host=typeオプションで与えてください。 typeは、sun4の様なシステムタイプの短い名前や、3つのフィール ドを持つ標準的な名前です。

cpu-company-system

それぞれのフィールドでの可能な値は、ファイルconfig.subを見てくだ さい。config.subがパッケージに含まれていない場合は、パッケージに ホストタイプを知らせる必要がありません。

クロスコンパイルのためのコンパイラツールを作っている場合、同様に、コード を生成するシステムのタイプを選択するための--target=typeオプ ションと、パッケージをコンパイルするシステムタイプを選択するための --build=typeオプションを使うこともできます。

デフォルトの共有

configureを共有するため、デフォルト値をセットしたい場合、 config.siteと呼ばれる、サイトシェルスクリプトを作ることができ、そ れは、CC、cache_fileと、prefixの様な変数を与えます。 configureは、prefix/share/config.siteの存在を調べ、 そして、prefix/etc/config.siteの存在を調べます。 CONFIG_SITE環境変数を、サイトスクリプトのある場所にセットすること もできます。注意として、全てのconfigureスクリプトが、サイトスクリ プトを探すわけではないことがあげられます。

オペレーションの制御

configureは、処理方法をコントロールする以下のオプションを理解し ます。

--cache-file=file

./config.cacheの代わりに、fileにテストの結果を保存します。 デバッグのために、キャッシュできないようにするには、fileを /dev/nullにセットしてください。

--help

configureオプションの概要を出力して終了します。

--quiet

--silent

-q

調査したり作ったりしているメッセージを出力しません。通常の出力も全て省く ためには、(エラーメッセージは表示されるので)/dev/nullに、ファイル をリダイレクトしてください。

--srcdir=dir

ディレクトリdirで、パッケージのソースコードを探します。普通は、 configureは、ディレクトリを自動的に決定するはずです。

--version

configureの生成に使った、Autoconfのバージョンを出力し終了します。

configureは、同様に、広範囲では役に立たないかも知れないが、他のオ プションも受け入れます。

Recreating a Configuration

configureスクリプトはconfig.statusという名前のファイルを つくります。このファイルには、前回パッケージが作成されたときに どういう設定のためのオプションが指定されたのかが記述されています。 このファイルはshellスクリプトで、実行されると、再度おなじ設定を することができます。

config.statusに--recheckオプションをつけて実行することで、 config.status自体を更新することができます。 このオプションはconfigure自体を変更したときに有効です。 そのような場合、テストの結果は前回と今回で異なっている可能性がありますから。 --recheckオプションをつけてconfig.statusを実行した場合、 前回つけたのとおなじ引数、それから--no-createオプションと --no-recursionオプションをつけてconfigureが実行されます。 これらのオプションは、config.statusが実行されるのを防ぎ、 Makefileや他のファイルが更新されないようにし、 サブディレクトリのconfigureが実行されないようにします。 (このため、Makefileの中からconfig.statusが 呼べるようになっています。例題はsee Automatic Remaking参照)

config.statusは--helpと--versionのふたつの オプションも受け付けます。 --helpをつけると、config.statusのオプションの 概説を出力します。--versionをつけると、Autoconfの バージョンと、config.statusを作るときに使われた configureのオプションを出力します。

config.statusは、いくつかの環境変数を参照して動作を変更します:

CONFIG_SHELL

Variable

--recheckをつけたときconfigureを実行する際に、 使うべきshellを指定します。Bourne shell互換である必要があります。 デフォルトは/bin/shです。

CONFIG_STATUS

Variable

設定を記録するためのshellスクリプトの名前です。 デフォルト値は./config.statusです。この環境変数は あるパッケージが他のパッケージの一部を使っていて、 それらが別々に管理されているためconfigureスクリプトを 統合できない場合などに役立ちます。

以下の環境変数を使うことで、別々に配布されるパッケージが configureで求めたテスト結果を共有することができます。 あるパッケージが他のパッケージ(たとえば共有ライブラリ)の必要とする OS機能のsupersetを要求している場合に役立ちます。 以下の環境変数を使うと、config.statusにconfigure.inで 指定された以外のファイルを生成させることができます。 このため、生成されたファイルを他のパッケージから使うことができるのです。

CONFIG_FILES

Variable

@variable@の置換を行うべきファイル名。 デフォルトはconfigure.inでAC_OUTPUTに与えられた引数です。

CONFIG_HEADERS

Variable

Cの#defineディレクティブの置換を行うべきファイル名。 デフォルトはAC_CONFIG_HEADERに与えられた引数です。 AC_CONFIG_HEADERマクロが使われていない場合、 config.statusはこれを無視します。

上記の環境変数を使うことで、一部のファイルだけを再生成するような Makefileのルールを記述することができます。 例えば、see Automatic Remakingで挙げたルールでは、 configure.inが新しくなったときにはconfig.statusが 2回呼ばれます。もしこれが気に入らない場合、各ファイルをひとつづつ 更新するようなルールを記述することができます(訳註: かなり意訳):

config.h: stamp-h
stamp-h: config.h.in config.status
        CONFIG_FILES= CONFIG_HEADERS=config.h ./config.status
        echo > stamp-h

Makefile: Makefile.in config.status
        CONFIG_FILES=Makefile CONFIG_HEADERS= ./config.status

(configure.inがAC_CONFIG_HEADERマクロを使っていない場合、 makeルール内でCONFIG_HEADERSを指定する必要はありません)

Questions About Autoconf

Autoconfに関しては、いくつかの質問が頻繁に出ます。 それらのいくつかにお答えしましょう。

• Distributing: Distributing configure scripts.
• Why GNU m4: Why not use the standard m4?
• Bootstrapping: Autoconf and GNU m4 require each other?
• Why Not Imake: Why GNU uses configure instead of Imake.

Distributing configure Scripts

Autoconfが生成したconfigureスクリプトには配布制限はありますか?
configureスクリプトを使うプログラムに影響は?

Autoconfによって生成された設定スクリプトの配布に関しては、 なにも制限がありません。Autoconfバージョン1では、 生成された設定スクリプトもGPLによって保護されていました。 現在でも我々はソフトウェアの作者にGPLのような配布条件で 配布を行うことを推奨しますが、Autoconfを使うからといってそれが 必須なわけではありません。

configureに使われる可能性のあるファイルのうち、 config.h.inはあなたが指定したconfigure.inの 著作権表示に従います。config.h.inはconfigure.inと、 パブリックドメインのファイルacconfig.hから生成されるからです。 config.subとconfig.guessは、Autoconfに生成された configureスクリプトとともに使う場合にはあなたの パッケージの配布条件に従います。これはGPLの例外です。 install-shはXコンソーシアムによるもので、 著作権は放棄されています。

Why Require GNU m4?

なんでAutoconfはGNU m4を必要とするんですか?

多くのm4の実装では、マクロの大きさや数に決め打ちの制限があって、 Autoconfはそれをオーバしてしまいます。また、いくつかの組み込みマクロが 不足している場合があり、それらのマクロなしではAutoconfのような 洗練されたアプリケーションは記述しづらくなります。たとえばこんな マクロがない場合があります:

builtin
indir
patsubst
__file__
__line__

ソフトウェアの管理者はAutoconfだけを使えばよいし、GNU m4は 設定やインストールが簡単です。このため、GNU m4がインストール されていないといけない、というのは妥当と思われます。 GNUやGNU以外のフリーソフトウェアの管理者にはGNUユーティリティの 多くをインストールしている人がたくさんいます。なぜなら 彼らはGNUユーティリティが気に入っているからです。

How Can I Bootstrap?

AutoconfがGNU m4を必要としていて、GNU m4パッケージがAutoconfで
生成されたconfigureスクリプトを含んでいたら、どこから仕事をはじめたら
いいんですか? 鶏と卵問題になりませんか?

それは誤解です。 確かに、GNU m4パッケージはAutoconfで生成された configureスクリプトを含んでいます。 しかし、configureスクリプトを実行したり GNU m4パッケージをインストールしたりするのに Autoconfは必要ありません。 Autoconfはm4パッケージに含まれるconfigureスクリプトを 変更したい場合にだけ必要です。 ふつう、そのような変更はごく少数のひと(主にm4パッケージの メインテナ)しか行いません。

Why Not Imake?

なんでconfigureスクリプトでなしにImakeを使わないのですか?

幾人かのひとがこの質問の答えを書いてくれましたので、 それを翻案して載せたいと思います。

以下の答えはRichard Pixleyの答えをもとにしています:

Autoconfで生成されたスクリプトは、 しばしばパッケージを一度も動かしたことのないマシンでも動作します。 つまり、Autoconfスクリプトは新しいシステムのための設定を類推することが できるのです。 Imakeではこれはできません。

Imakeはホスト依存の情報を得るのに共用のデータベースを使います。 X11の配布はツールの集合でできているので、中央集権的にデータベースを 管理することには意味があります。

しかし、GNUのツールはそのように配布されていません。 各々のGNUツールには個別のmaintainerがいます。 maintainerは世界中に散らばっています。 共用のデータベースを使うと、「データベースの管理」という悪夢が待っています。 Autoconfは共用のデータベースのように見えるかもしれませんが、実際には違います。 Autoconfスクリプトは各ホストへの依存性を記述するのではなく、 プログラムの要求事項を記述しているのです。

GNUツール群を固有のツールの集合としてみるなら、 X11の場合と問題は似ているかもしれません。 でも、GNUの開発ツールはクロス開発にも使えます。 しかも、どんなホストとターゲットの組み合わせについても使えますし、 全ての組み合わせは同時におなじマシンにインストールできます。 さらに、ホスト独立なファイルをマシン間で共有するようにもできます。 Imakeはこの問題に対して解を与えていません。

Imakeのtemplateはある種の標準化です。 GNUのcoding standardは同じ問題について、 Imakeの課する制約をいれることなく解決を与えています。

以下はPer Bothnerによるさらなる解説です:

Imakeの利点として、巨大なMakefileをcppの#includeと マクロ機構を使って簡単に生成できる、ということがあります。 しかし、cppはプログラマブルではありません。 cppでは限られた条件文しか書けませんし、ループは記述できません。 cppでは実行環境を調べることもできません。

以上の問題点は全て、cppでなしにshを使うことで解決できます。 shellは完全にプログラマブルです。マクロの置換、他のshellスクリプトの 実行(や取り込み)もできますし、実行環境を調べることもできます。

Paul Eggertがさらに詳細を述べています:

Autoconfを使う場合には、パッケージのインストールをするひとは 「Imake自体がきちんとインストールされて正しく動作する」ことを仮定しなくて 済みます。 Imakeに慣れたひとには、これはたいした利点とは思えないかもしれません。 しかし、多くのホストではImakeはインストールされていなかったり、 標準インストールの状態ではうまく動作しなかったりします。 そして、パッケージのインストールにImakeを使うと、 Imakeはパッケージをホストにインストールする際の障害になります。 例えば、Imake templateと設定ファイルがホストに正しく インストールされていないことがあります。 Imakeを使ったインストール手順では、 全てのソースファイルが巨大なdirectory treeに格納されていると 仮定していることがあります。 Imakeの設定ファイルは単一のコンパイラを仮定していて、 それがパッケージをインストールするのに使いたいコンパイラと 違うかもしれません。 パッケージの仮定しているImakeのバージョンと、 実際ホストにインストールされているImakeのバージョンが異なるかもしれません。 Autoconfを使う場合、このような問題は稀です。 パッケージに、独立して動く自動設定処理プログラムが付属しているからです。

Imakeを使っていると、makeとCプリプロセッサの予期していない 動作に悩まされることがよくあります。 CプリプロセッサはCのプログラムを処理するために設計されたもので、 Makefileを処理するためのものではありません。 Autoconfを使うなら簡単です。 Autoconfはバックエンドに汎用プリプロセッサm4を使っています。 m4を使うのは、 パッケージの作者がconfigureスクリプトを作成するときです。 つまり、インストールをするときにはプリプロセッサは必要ありません (訳註: この行激しく意訳)。

最後にMark Eichinが言うには:

Imakeには拡張性がありません。 Imakeに新しい機能を加えようとすると、 独自のproject templateを作成しなければなりません。 しかも、そのtemplateには既存のtemplateの大部分をコピーして含めねば なりません。 つまり、洗練された開発プロジェクトでは、 ベンダが提供するtemplateは必要なところをカバーしてくれないので 意味がありません (開発プロジェクトがX11向けなら話は別ですが)。

逆の見方をすると:

Imakeにはひとつだけ、configureに対して有利な点があります。多くの 場合、ImakefileはMakefile.inよりもずっと短く、冗長性があり ません。これを改善する方法はあります。Kerberos V5では、ツリーじゅうの Makefileの先頭と末尾の部分をpost.inとpre.inとして共 通化し、Makefile.inからMakefileを生成するときにこれらを読 み込むようにしました。これは、多くの共通のものが、普通configureセッ トアップにあるものさえ、繰りさえされることを意味します。

Upgrading From Version 1

Autoconfバージョン2はバージョン1とほぼ互換です。 しかし、いくつかの点についてよりよいやり方が導入されていますし、 バージョン1の汚かった点がいくつか除かれています。 このため、あなたのconfigure.inの洗練度に依存しますが、 手作業でconfigure.inを一部書き換える必要があるかもしれません。 この章ではバージョン2への移行のために注意すべき点を挙げます。 移行すると、生成されるconfigureスクリプトはバージョン2の 新機能によりよりよくなるでしょう。 変更点はAutoconfの配布キットに含まれるNEWSというファイルに まとめられています。

まず、バージョン1.1かそれ以降のGNU m4がインストール されていることを確認してください。できればバージョン1.3かそれ 以降のものが望ましいです。バージョン1.1以前のものには、Autoconfが 動作しなくなるようなバグがあります。バージョン1.3またはそれ以降は 1.3以前のバージョンより大幅に早く動作します。 バージョン1.3およびそれ以降では、diversionの実装がより効率的になり、 内部状態をファイルに保存することができるため高速に再呼び出しが可能です。

• Changed File Names: Files you might rename.
• Changed Makefiles: New things to put in Makefile.in.
• Changed Macros: Macro calls you might replace.
• Invoking autoupdate: Replacing old macro names in configure.in.
• Changed Results: Changes in how to check test results.
• Changed Macro Writing: Better ways to write your own macros.

Changed File Names

もし、(特定のパッケージのソースディレクトリに置いてあるのではなくて) Autoconfと一緒にaclocal.m4がインストールされていたら ファイル名をacsite.m4に変更する必要があります。 See Invoking autoconf

install.shをパッケージと一緒に配布する場合、 ファイル名をinstall-shにしてください。 これは、makeの組み込みルールが勝手にinstall というファイルを生成してしまうのを防ぐためです。 AC_PROG_INSTALLは両方のファイル名を調べますが、 新しい名前を使う方が望ましいです。

config.h.topまたはconfig.h.botを使っている場合、 そのまま使い続けることができます。可能ならacconfig.hに 取り込んだ方がファイルがごみごみしなくていいでしょう。 See Invoking autoheader

Changed Makefiles

Makefile.inに@CFLAGS@、@CPPFLAGS@ それから@LDFLAGS@を追加してください。 追加すると、configureが実行されたときの環境がそれらの 変数の値に反映されます。これは必ず必要なわけではありませんが、 ユーザの利便のためになります。

Makefile以外で、AC_OUTPUTで出力されるファイルのもとの ファイルには、コメント中に@configure_input@を追加してください。 追加すると、「このファイルはconfigureに生成された」という コメントが出力ファイルに入ります。 AC_OUTPUT中で、あらゆる形式のコメントを自動選択するのは 無理になりました。

config.logとconfig.cacheを、Makefileの distcleanターゲットで消去されるファイルのリストに含めてください。

以下のような定義をMakefile.inにしていたら:

prefix = /usr/local
exec_prefix = ${prefix}

以下のように書き換える必要があります:

prefix = @prefix@
exec_prefix = @exec_prefix@

@が前後についていない変数を書き換えるふるまいは 削除されました。

Changed Macros

多くのマクロがAutoconfバージョン2で改名されました。 古い名前を使うこともできますが、新しいものの方がわかりやすく、 ドキュメントとの対応もとれていて探しやすいです。 新しい名前と古い名前の対応表はSee Old Macro Namesを参照してください。 autoupdateを使うと、古いマクロ名を含むconfigure.inを 新しいマクロ名を使うように変換できます。See Invoking autoupdate参照。

いくつかのマクロはよりうまく働く類似のマクロで置き換えられましたが、 呼び出し方法が互換でないものがあります。 autoconfを呼び出した際にobsoleteなマクロを呼び出している 旨警告が表示された場合、警告を無視することもできます。 しかし、警告に従って書き換えを行った方が生成される configureスクリプトはうまく動作します。 特に、テストの結果を表示するメカニズムが変更されています。 echoや(AC_COMPILE_CHECK経由での)AC_VERBOSEなどを 使っている場合には、AC_MSG_CHECKINGとAC_MSG_RESULTに 移行した方がconfigureの出力がうまく見えます。 See Printing Messagesを参照のこと。 これらのマクロはキャッシュとともに使うと最もうまく動きます。 See Caching Results参照。

Using autoupdate to Modernize configure

autoupdateはAutoconfマクロを古い名前で呼び出している configure.inを、現在のマクロ名で呼び出すように変換する プログラムです。 Autoconfのバージョン2では、多くのマクロが統一的でわかりやすい 命名規則に従うよう改名されました。 新しい命名規則についてはSee Macro Namesを参照。 古い名前を使うこともできますが、新しいものに移行した使った方が configure.inが読みやすいですし、現在のAutoconfのドキュメントとの 対応もとれていて探しやすいです。 (新しい名前と古い名前の対応表はSee Old Macro Namesを参照)

引数なしで呼ばれた場合、autoupdateはconfigure.inを 更新します。その際、もとのファイルはファイル名に~ (または環境変数SIMPLE_BACKUP_SUFFIXの内容)を追加したファイル名で 保存されます。autoupdateに引数を与えた場合、 configure.inのかわりにそのファイルを読み込んで標準出力に 結果を書き出します。

autoupdateは以下のオプションを受け付けます:

--help

-h

コマンドラインオプションの説明を出力して終了します。

--macrodir=dir

-m dir

デフォルトのディレクトリではなしに、 ディレクトリdirに格納されている Autoconfマクロファイルを参照します。 ディレクトリ名を 環境変数AC_MACRODIRに 設定しても変えられます。 オプションは環境変数より優先されます。

--version

autoupdateのバージョン番号を表示して終了します。

Changed Results

shell変数DEFSの値を調べることで以前のテスト結果を参照 している場合、テスト結果のキャッシュをしているshell変数を 調べるように変更する必要があります。 DEFSは出力ファイル生成時に設定されるようになったので、 configure実行中には存在しないようになりました。 バージョン1からの変更は、shell変数DEFSの 設定のたび、つまりAC_DEFINEを呼ぶたびに 正しく内容をquoteするのが面倒で非効率的であったことによります。 See Cache Variable Names参照。

例えば、Autoconfバージョン1用のconfigure.inの一部が このようだったとすると:

AC_HAVE_FUNCS(syslog)
case "$DEFS" in
*-DHAVE_SYSLOG*) ;;
*) # syslog is not in the default libraries.  See if it's in some other.
  saved_LIBS="$LIBS"
  for lib in bsd socket inet; do
    AC_CHECKING(for syslog in -l$lib)
    LIBS="$saved_LIBS -l$lib"
    AC_HAVE_FUNCS(syslog)
    case "$DEFS" in
    *-DHAVE_SYSLOG*) break ;;
    *) ;;
    esac
    LIBS="$saved_LIBS"
  done ;;
esac

バージョン2用はこのようになります:

AC_CHECK_FUNCS(syslog)
if test $ac_cv_func_syslog = no; then
  # syslog is not in the default libraries.  See if it's in some other.
  for lib in bsd socket inet; do
    AC_CHECK_LIB($lib, syslog, [AC_DEFINE(HAVE_SYSLOG)
      LIBS="$LIBS $lib"; break])
  done
fi

AC_DEFINE_UNQUOTEDのバグを回避するためにダブルクォートの 前にbackslashを入れていた場合、それらを取り除く必要があります。 AC_DEFINE_UNQUOTEDは現在想定されるとおりに動き、 backquote以外のquoteを特別扱いしません。 See Setting Output Variables参照。

Autoconfマクロによって設定されるshell変数で真偽値をとるものは、 「真」の場合yesに設定されるようになりました。 マクロの多くは「偽」の場合noを使いますが、 バックワードコンパチビリティのために空文字列を使うものもあります。 shell変数が1とかtとかに設定されることを仮定している場合、 スクリプトを変更する必要があります。

Changed Macro Writing

自分でマクロを定義する場合、defineのかわりにAC_DEFUN を使わねばならないようになりました。AC_DEFUNは自動的に AC_PROVIDEを呼び出します。 これにより、AC_REQUIREに呼ばれたマクロが他のマクロを邪魔 しないようなり、checking...というメッセージがダブって 表示されるのを防止できます。古い方法でマクロを定義しても 実害はありませんが、不便ですしかっこわるいです。 See Macro Definitions参照。

マクロを定義するために、Autoconfについてきたマクロの定義を 読んでらっしゃるのではないかと思います。新しいバージョンの マクロ定義を読むのはいいことだと思います。書き方が わかりやすくなっていますし、新しい機能も活用しています。

ドキュメントに書かれていないAutoconfの内部構造(マクロ、変数や 実装上の抜け道)を使ってトリッキーなことをしている場合、バージョンの 違いによる変化に影響されていないかをチェックしてください。 もしかしたら、ずるをしないでもバージョン2で用意されているやりかたで 同じ事ができるかもしれません。できないかもしれませんけど。

自分で記述したテストを高速にするために、キャッシュを使いましょう。 あなたの記述したテストが、汎用的なマクロとして一般化できるかどうか 考えましょう。

History of Autoconf

以下のことを不思議に思うかもしれません。なぜAutoconfは元々書かれたのです か? どのようにして現在の形式になったのですか? (なぜそれはゴリラによく似て いるのですか?)不思議に思っていない場合、この章は有用な情報を含んでいない ので省略した方がましです。不思議に思っている場合、軽くながして ください...

• Genesis: Prehistory and naming of configure.
• Exodus: The plagues of m4 and Perl.
• Leviticus: The priestly code of portability arrives.
• Numbers: Growth and contributors.
• Deuteronomy: Approaching the promises of easy configuration.

Genesis

1991年6月、私はFree Software Foundationのため、GNUユーティリティーの多く を保守していました。それらが、より多くのプラットホームに移植され、より多 くのプログラムが加えられたので、ユーザーは、Makefileで、多くの -Dオプション(およそ２０)を選択する必要があり、厄介になりました。 特に私のために、--私は、異なるシステムで、それぞれの新しいいリリースを テストする必要がありました。そして、私はfileutilsパッケージのため、正し いセッティングを見つけるため、小さなシェルスクリプトを書き、fileutils 2.0の一部としてリリースしました。そのconfigureは、翌月、いくつか の他のGNUユーティリティパッケージのための、configureスクリプトを 作るため、(手作業で)改造すると良く働きました。Brian Berlinerも、私のスク リプトを、CVSリビジョンコントロールシステム用に改造しました。

その夏の後、私はRichard StallmanとRichard Pixleyが、GNUコンパイラツール で使う、類似のスクリプトを開発していたことを知りました。それで、私は configureスクリプトを、発展するインタフェースをサポートするため、 改造しました。テンプレートとして、Makefile.inという名前のファイル を使い、(多くあるなかの)最初のオプション+srcdirを追加し、 config.statusファイルを作りました。

Exodus

ユーザーからのフィードバックを得るにつれ、私は、スクリプトのそれぞれの良 く似た変更に対し、検索と置換、カットアンドペーストにEmacsを使い、多くの 改良点を組み入れました。私が、GNUユーティリティパッケージに、 configureスクリプトを使うため改造するにつれ、手作業でのアップグレー ドは、非現実的になりました。GNUグラフィックユーティリティの管理者Rich Murpheyは、configureスクリプトは素晴らしいというメールを送ってく れ、私がそれらを生成するツールを持っているなら送って欲しいという依頼があ りました。ダメだと思いましたが、そうするべきだと思いました!。それで、私 はそれらを生成する仕事を始めました。手書きのconfigureスクリプトの 奴隷から、Autoconfで簡単に始める裕福で簡単な旅が始まりました。

Cygnus configureは、そのころには開発されていて、表ベースで動いて いました。それは、主に推測しにくい(オブジェクトファイルの、フォーマット の詳細としての)特徴の、小さな数字を使って、システムタイプを不連続な数字 で、主に扱われることになっています。Brian Foxが、Bashのために開発してい た、自動的なコンフィグレーションシステムは、類似のアプローチをとります。 一般的に使うため、それぞれのオペレーティングシステムが持つ、それぞれ異な る特徴の、最新のデータベースを管理しようとすることは、望みがないように思 われました。それは、その場その場で--特に、人々がローカルでハックしたり、 ベンダーがインストールしたパッチを持つ、ハイブリッドなシステムで、おおま かな特徴を調べるために、容易で信頼性が高いです。

私は Cygnus configureに類似のアーキテクチャを使おうと考え、それは 実行時には、configure.inの部品を読み込む、一つの configure スクリプトです。しかし、全てのパッケージで、全ての特徴を配布する必要は望 まなかったので、プロセッサーによって、それぞれの configure.inから、 異なるconfigureを作らせる処理にしました。そのアプローチは、多くの 制御と柔軟性をもたらしました。

私は、Larry Wall、Harlan Stennと、Raphael Manfrediによる、Metaconfigを使っ てみようとしましたが、いくつかの理由でやめました。それが生成する Configureスクリプトは、対話的で、それが非常に不都合だと分かりまし た。私は、それが行う(ライブラリ関数のような)特徴の調べ方が、好きでありま せんでした。さらに、まだ管理されているかどうか分かりませんでした。 Configureスクリプトは、(System V R4とNeXTのような)近代的なシステ ムでは働かないように思えました。特徴の有無の反応で、できることがあまり柔 軟ではありませんでした。学ぶことが難しいと思いました。そして、必要以上に、 あまりに大きく複雑でした(私は、そのとき、Autoconfが結局どれくらい成長す るのか、理解していませんでした)。

私は、configureスクリプトの私のスタイルを生成するため、Perlを使う ことを考えましたが、m4が、簡単なテキスト代入の仕事により適してい て、出力が暗黙なので、より小さい方法になると思い、決定しました。さらに、 みんな既にそれを持っています。(最初は、私はGNUが拡張したm4に依存 しませんでした。)また、Maryland大学の私の友達は、tvtwmを含む、い くつかのプログラムのフロントエンドとして、m4を、最近位置付けてい て、私は新しい言語への挑戦に興味が湧きました。

Leviticus

私のconfigureスクリプトは、ユーザーの対話的な干渉無しで、システム の能力を自動的に決定するので、それを生成するプログラムを、Autoconfigと呼 ぶことに決定しました。しかし、バージョンナンバーを付けると、UNIXファイル システムではあまりに長い名前なので、短くしてAutoconfとしました。

1991年秋、私は、m4マクロの手書きのスクリプトの部品をまとめ、調査 時に使う特徴を加えたり、テクニックを上達させることを続けるにつれて、私に フィードバックを与えてもらうため、移植性の聖杯にちなんだ探求者たちのグルー プ(つまり、アルファテスター)を、呼びました。テスターの間で著明な人は、以 下の通りです。 Pinardは、m4を実行するためと、未解決のマクロの呼び出しを調べるた めの、autoconfシェルスクリプトの作り方の、アイディアを持ってきま した。Richard Pixleyは、インクルードファイルやシンボルを探すため、より正 確な結果を求めて、ファイルシステムを探す代わりに、コンパイラの実行を提案 しました。Karl Berryは、Autoconfに、コンフィグレーションTeXを与え、ド キュメントに、マクロインデクッスを加えました。そして、Ian Taylorは、 -DオプションをMakefileに置く代わりとして、Cヘッダファイル を作るためのサポートを加え、UUCPパッケージでAutoconfが使えるようになりま した。アルファテスターは、リリースからリリースで、変化するAutoconfマクロ の、名前と呼び出し方法に対し、何度も何度も、ファイルを機嫌良く調整してく れました。彼らは皆、多くの特定の調査、偉大なアイディアそして、バグフィク スを提供してくれました。

Numbers

1992年7月、何カ月ものアルファテストの後で、私は Autoconf 1.0をリリースし、 それを使って多くのGNUパッケージを改造しました。私は、それらに対する、あ まりに肯定的な反応に驚きました。私が追跡記録できる以上の多くの人々が、そ れを使い始め、それは、GNUプロジェクトの一部ではない(TCL、FSPとKerberos V5のような)ソフトウェアで働かせている人も含みます。Autoconfは、 configureを使っている多くの人が、彼らが遭遇した問題を報告してくれ るので、急速に改善され続けました。

Autoconfは、m4実行の良い耐久テストだということが分かりました。 UNIX m4は、Autoconfが定義する、マクロの長さでコアダンプを吐き始め、 いくつかのバグが、GNU m4でも同様に明らかになりました。結局、私達 はGNU m4のみが持つ特徴が必要だと認識しました。4.3BSD m4は、 特に組み込みマクロのセットが足りず、System Vバージョンはましですが、私達 が必要とするもの全てを、いまだに供給してくれません。

人々が、Autoconfをより強い圧力下(そして、私が予想していなかった利用)の下 で利用するにつれ、更なる開発が発生しました。Karl BerryはX11に対する調査 を加えました。david zuhnはC++サポートを寄付してくれました。 Pinardは、無効な引数を診断させるようにしました。Jim Blandyは勇敢にも、後 の改良のためのワークグランドとなるよう、GNU Emacsのコンフィグレーション に強要しました。Roland McGrathは、GNU Cライブラリのコンフィグレーション に使い、Cヘッダテンプレートファイルを自動的に作る、autoheaderスク リプトを書き、configureに、--verboseオプションを加えました。 Noah Friedmanは、--macrodirオプションと AC_MACRODIR環境変 数を加えました。(彼は、"ソフトウェアパッケージを、Autoconfを使うものに 改造してください"と言うことを意味する autoconfiscateという言葉も 作り出しました。)RolandとNoahは、 AC_DEFINEでの引用の保護を改善し、 特に私が1993年の2月から6月まで移植性の問題にうんざりしているとき、多くの バグを直しました。

Deuteronomy

長い間望まれていた、主な特徴のリストが蓄積され、様々な人々のパッチの、数 年間の効果は、残りのcruftを残したままでした。1994年4月のCygnus Supportの ための仕事中に、私はautoconfの主な修正を始めました。私は、Autoconfが欠け ていて、david zuhnとKen Raeburnの助けで、Cygnus configureが関連し た部分がほとんどですが、Cygnus configureの特徴のほとんどを加えま した。これらの特徴は、config.sub、config.guess、 --hostと、--targetを使うサポート、ファイルをリンクさせるこ と、サブディレクトリでconfigureを実行することを含みます。これらの 特徴に加え、Autoconfを使うように、KenはGNU asを対応し、Rob Savoye はDejaGNUを対応しました。

私は、他の人々の要求に答え、より多くの特徴を加えました。多くの人々は、 configureスクリプトが、実行時の調査結果を共有できるよう求め、それ は、(特に、Cygnusのような、大きなソースツリーのコンフィグレーション時に) イライラする程遅かったためです。Mike Haertelは、サイト特定の初期化スクリ プトを加えることを提案しました。MS-DOSでアンパックが必要なものを配布して いる人々は、生成されるファイル名が、config.h.inのように二つのドッ トを含むので、ファイル名の.in拡張子に優先するよう求めました。Jim Averaは、AC_DEFINEとAC_SUBSTの引用を使う問題の、拡張試験を 行い、彼の洞察は重要な改良につながりました。Richard Stallmanは、Emacsの configureスクリプトをデバッグする人々を助けるため、 /dev/nullの代わりにconfig.logに、コンパイラ出力を送るよう 頼みました。

私は、プログラム品質に不満があり、他の変更をしました。私は、メッセージで、 あまり曖昧でない調査結果が見えるようにし、常に結果を出力するようにしまし た。私はマクロの名前を組織化し、コーディングスタイルの矛盾をきれいにしま した。私は、Autoconfを使う、ソースコードパッケージの改造を助けるため開発 した、追加のユーティリティを加えました。 Pinardの助けで、私は、マクロを、お互いのメッセージが中断しないようにしま した。(その特徴は、GNU m4のパフォーマンスのボトルネックを明らかに し、彼はすぐに修正しました!)私は、人々が解決を望むドキュメント周りの問題 を再編成しました。そして、私は、経験から、Autoconfを変更したとき、明らか に退化する傾向が分かっているので、テストスイートを始めました。

再び、貴重なフィードバックをくれたアルファテスターです。特に、 Pinard、Jim Meyering、Karl Berry、Rob Savoye、Ken Raeburnと、Mark Eichin です。

最終的に、バージョン2.0が用意できました。そしてたくさんの喜びがありまし た。(そして私は再び自由な時間を持ちます。私は考えます。これは正当な権利 だ。)

Old Macro Names

Autoconfのバージョン2では、多くのマクロが統一的でわかりやすい 命名規則に従うよう改名されました。

以下は、改名されたマクロの古い名前と現在の名前のリストです。 バックワードコンパチビリティのためにautoconfは 古い名前を受け付けますが、古い名前はobsoleteです。 新しい命名規則についてはSee Macro Names参照。

AC_ALLOCA

AC_FUNC_ALLOCA

AC_ARG_ARRAY

あまり役立たないので削除

AC_CHAR_UNSIGNED

AC_C_CHAR_UNSIGNED

AC_CONST

AC_C_CONST

AC_CROSS_CHECK

AC_C_CROSS

AC_ERROR

AC_MSG_ERROR

AC_FIND_X

AC_PATH_X

AC_FIND_XTRA

AC_PATH_XTRA

AC_FUNC_CHECK

AC_CHECK_FUNC

AC_GCC_TRADITIONAL

AC_PROG_GCC_TRADITIONAL

AC_GETGROUPS_T

AC_TYPE_GETGROUPS

AC_GETLOADAVG

AC_FUNC_GETLOADAVG

AC_HAVE_FUNCS

AC_CHECK_FUNCS

AC_HAVE_HEADERS

AC_CHECK_HEADERS

AC_HAVE_POUNDBANG

AC_SYS_INTERPRETER (呼び出し方法変更)

AC_HEADER_CHECK

AC_CHECK_HEADER

AC_HEADER_EGREP

AC_EGREP_HEADER

AC_INLINE

AC_C_INLINE

AC_LN_S

AC_PROG_LN_S

AC_LONG_DOUBLE

AC_C_LONG_DOUBLE

AC_LONG_FILE_NAMES

AC_SYS_LONG_FILE_NAMES

AC_MAJOR_HEADER

AC_HEADER_MAJOR

AC_MINUS_C_MINUS_O

AC_PROG_CC_C_O

AC_MMAP

AC_FUNC_MMAP

AC_MODE_T

AC_TYPE_MODE_T

AC_OFF_T

AC_TYPE_OFF_T

AC_PID_T

AC_TYPE_PID_T

AC_PREFIX

AC_PREFIX_PROGRAM

AC_PROGRAMS_CHECK

AC_CHECK_PROGS

AC_PROGRAMS_PATH

AC_PATH_PROGS

AC_PROGRAM_CHECK

AC_CHECK_PROG

AC_PROGRAM_EGREP

AC_EGREP_CPP

AC_PROGRAM_PATH

AC_PATH_PROG

AC_REMOTE_TAPE

あまり役立たないので削除

AC_RESTARTABLE_SYSCALLS

AC_SYS_RESTARTABLE_SYSCALLS

AC_RETSIGTYPE

AC_TYPE_SIGNAL

AC_RSH

あまり役立たないので削除

AC_SETVBUF_REVERSED

AC_FUNC_SETVBUF_REVERSED

AC_SET_MAKE

AC_PROG_MAKE_SET

AC_SIZEOF_TYPE

AC_CHECK_SIZEOF

AC_SIZE_T

AC_TYPE_SIZE_T

AC_STAT_MACROS_BROKEN

AC_HEADER_STAT

AC_STDC_HEADERS

AC_HEADER_STDC

AC_STRCOLL

AC_FUNC_STRCOLL

AC_ST_BLKSIZE

AC_STRUCT_ST_BLKSIZE

AC_ST_BLOCKS

AC_STRUCT_ST_BLOCKS

AC_ST_RDEV

AC_STRUCT_ST_RDEV

AC_SYS_SIGLIST_DECLARED

AC_DECL_SYS_SIGLIST

AC_TEST_CPP

AC_TRY_CPP

AC_TEST_PROGRAM

AC_TRY_RUN

AC_TIMEZONE

AC_STRUCT_TIMEZONE

AC_TIME_WITH_SYS_TIME

AC_HEADER_TIME

AC_UID_T

AC_TYPE_UID_T

AC_UTIME_NULL

AC_FUNC_UTIME_NULL

AC_VFORK

AC_FUNC_VFORK

AC_VPRINTF

AC_FUNC_VPRINTF

AC_WAIT3

AC_FUNC_WAIT3

AC_WARN

AC_MSG_WARN

AC_WORDS_BIGENDIAN

AC_C_BIGENDIAN

AC_YYTEXT_POINTER

AC_DECL_YYTEXT

Environment Variable Index

以下は、Autoconfが参照する環境変数の名前を、アルファベット順に 並べたリストです。

• AC_MACRODIR: Invoking autoupdate, Invoking autoheader, Invoking autoreconf, Invoking autoconf, Invoking ifnames, Invoking autoscan
• CONFIG_FILES: Invoking config.status
• CONFIG_HEADERS: Invoking config.status
• CONFIG_SHELL: Invoking config.status
• CONFIG_SITE: Site Defaults
• CONFIG_STATUS: Invoking config.status
• SIMPLE_BACKUP_SUFFIX: Invoking autoupdate

Output Variable Index

以下はAutoconfが(Makefileなどの)出力ファイルを作成する際に、 置換を行う変数名のアルファベット順リストです。 置換動作に関してはSee Setting Output Variablesを参照。

• ALLOCA: Particular Functions
• AWK: Particular Programs
• bindir: Preset Output Variables
• build: System Type Variables
• build_alias: System Type Variables
• build_cpu: System Type Variables
• build_os: System Type Variables
• build_vendor: System Type Variables
• CC: UNIX Variants, Particular Programs
• CFLAGS: Particular Programs, Preset Output Variables
• configure_input: Preset Output Variables
• CPP: Particular Programs
• CPPFLAGS: Preset Output Variables
• CXX: Particular Programs
• CXXCPP: Particular Programs
• CXXFLAGS: Particular Programs, Preset Output Variables
• datadir: Preset Output Variables
• DEFS: Preset Output Variables
• exec_prefix: Preset Output Variables
• EXEEXT: System Services
• F77: Particular Programs
• FFLAGS: Particular Programs, Preset Output Variables
• FLIBS: Fortran 77 Compiler Characteristics
• host: System Type Variables
• host_alias: System Type Variables
• host_cpu: System Type Variables
• host_os: System Type Variables
• host_vendor: System Type Variables
• includedir: Preset Output Variables
• infodir: Preset Output Variables
• INSTALL: Particular Programs
• INSTALL_DATA: Particular Programs
• INSTALL_PROGRAM: Particular Programs
• INSTALL_SCRIPT: Particular Programs
• KMEM_GROUP: Particular Functions
• LDFLAGS: Preset Output Variables
• LEX: Particular Programs
• LEX_OUTPUT_ROOT: Particular Programs
• LEXLIB: Particular Programs
• libdir: Preset Output Variables
• libexecdir: Preset Output Variables
• LIBOBJS: Structures, Generic Functions, Particular Functions
• LIBS: UNIX Variants, Preset Output Variables
• LN_S: Particular Programs
• localstatedir: Preset Output Variables
• mandir: Preset Output Variables
• NEED_SETGID: Particular Functions
• OBJEXT: System Services
• oldincludedir: Preset Output Variables
• prefix: Preset Output Variables
• program_transform_name: Transforming Names
• RANLIB: Particular Programs
• sbindir: Preset Output Variables
• sharedstatedir: Preset Output Variables
• srcdir: Preset Output Variables
• subdirs: Subdirectories
• sysconfdir: Preset Output Variables
• target: System Type Variables
• target_alias: System Type Variables
• target_cpu: System Type Variables
• target_os: System Type Variables
• target_vendor: System Type Variables
• top_srcdir: Preset Output Variables
• X_CFLAGS: System Services
• X_EXTRA_LIBS: System Services
• X_LIBS: System Services
• X_PRE_LIBS: System Services
• YACC: Particular Programs

Preprocessor Symbol Index

以下は、Autoconfマクロが定義するCプリプロセッサシンボルの アルファベット順リストです。 Autoconfを利用する場合、Cソースコード中の#ifディレクティブで 以下のシンボルを使う必要があります。

• __CHAR_UNSIGNED__: C Compiler Characteristics
• _ALL_SOURCE: UNIX Variants
• _MINIX: UNIX Variants
• _POSIX_1_SOURCE: UNIX Variants
• _POSIX_SOURCE: UNIX Variants
• _POSIX_VERSION: Particular Headers
• C_ALLOCA: Particular Functions
• CLOSEDIR_VOID: Particular Functions
• const: C Compiler Characteristics
• DGUX: Particular Functions
• DIRENT: Particular Headers
• F77_NO_MINUS_C_MINUS_O: Particular Programs
• GETGROUPS_T: Particular Typedefs
• GETLODAVG_PRIVILEGED: Particular Functions
• GETPGRP_VOID: Particular Functions
• gid_t: Particular Typedefs
• HAVE_ALLOCA_H: Particular Functions
• HAVE_CONFIG_H: Configuration Headers
• HAVE_DIRENT_H: Particular Headers
• HAVE_DOPRNT: Particular Functions
• HAVE_function: Generic Functions
• HAVE_GETMNTENT: Particular Functions
• HAVE_header: Generic Headers
• HAVE_LONG_DOUBLE: C Compiler Characteristics
• HAVE_LONG_FILE_NAMES: System Services
• HAVE_MMAP: Particular Functions
• HAVE_NDIR_H: Particular Headers
• HAVE_RESTARTABLE_SYSCALLS: System Services
• HAVE_ST_BLKSIZE: Structures
• HAVE_ST_BLOCKS: Structures
• HAVE_ST_RDEV: Structures
• HAVE_STRCOLL: Particular Functions
• HAVE_STRFTIME: Particular Functions
• HAVE_STRINGIZE: C Compiler Characteristics
• HAVE_SYS_DIR_H: Particular Headers
• HAVE_SYS_NDIR_H: Particular Headers
• HAVE_SYS_WAIT_H: Particular Headers
• HAVE_TM_ZONE: Structures
• HAVE_TZNAME: Structures
• HAVE_UNISTD_H: Particular Headers
• HAVE_UTIME_NULL: Particular Functions
• HAVE_VFORK_H: Particular Functions
• HAVE_VPRINTF: Particular Functions
• HAVE_WAIT3: Particular Functions
• inline: C Compiler Characteristics
• INT_16_BITS: C Compiler Characteristics
• LONG_64_BITS: C Compiler Characteristics
• MAJOR_IN_MKDEV: Particular Headers
• MAJOR_IN_SYSMACROS: Particular Headers
• mode_t: Particular Typedefs
• NDIR: Particular Headers
• NEED_MEMORY_H: Particular Headers
• NEED_SETGID: Particular Functions
• NLIST_NAME_UNION: Particular Functions
• NLIST_STRUCT: Particular Functions
• NO_MINUS_C_MINUS_O: Particular Programs
• off_t: Particular Typedefs
• pid_t: Particular Typedefs
• RETSIGTYPE: Particular Typedefs
• SELECT_TYPE_ARG1: Particular Functions
• SELECT_TYPE_ARG234: Particular Functions
• SELECT_TYPE_ARG5: Particular Functions
• SETPGRP_VOID: Particular Functions
• SETVBUF_REVERSED: Particular Functions
• size_t: Particular Typedefs
• STDC_HEADERS: Particular Headers
• SVR4: Particular Functions
• SYS_SIGLIST_DECLARED: Particular Headers
• SYSDIR: Particular Headers
• SYSNDIR: Particular Headers
• TIME_WITH_SYS_TIME: Structures
• TM_IN_SYS_TIME: Structures
• uid_t: Particular Typedefs
• UMAX: Particular Functions
• UMAX4_3: Particular Functions
• USG: Particular Headers
• vfork: Particular Functions
• VOID_CLOSEDIR: Particular Headers
• WORDS_BIGENDIAN: C Compiler Characteristics
• YYTEXT_POINTER: Particular Programs

Macro Index

以下は、Autoconfマクロのアルファベット順リストです。 リストを使いやすくするため、マクロ名先頭のAC_は除いてあります。

• AIX: UNIX Variants
• ALLOCA: Old Macro Names
• ARG_ARRAY: Old Macro Names
• ARG_ENABLE: Package Options
• ARG_PROGRAM: Transforming Names
• ARG_WITH: External Software
• BEFORE: Suggested Ordering
• C_BIGENDIAN: C Compiler Characteristics
• C_CHAR_UNSIGNED: C Compiler Characteristics
• C_CONST: C Compiler Characteristics
• C_CROSS: Test Programs
• C_INLINE: C Compiler Characteristics
• C_LONG_DOUBLE: C Compiler Characteristics
• C_STRINGIZE: C Compiler Characteristics
• CACHE_CHECK: Caching Results
• CACHE_LOAD: Caching Results
• CACHE_SAVE: Caching Results
• CACHE_VAL: Caching Results
• CANONICAL_HOST: Canonicalizing
• CANONICAL_SYSTEM: Canonicalizing
• CHAR_UNSIGNED: Old Macro Names
• CHECK_FILE: Generic Programs
• CHECK_FILES: Generic Programs
• CHECK_FUNC: Generic Functions
• CHECK_FUNCS: Generic Functions
• CHECK_HEADER: Generic Headers
• CHECK_HEADERS: Generic Headers
• CHECK_LIB: Libraries
• CHECK_PROG: Generic Programs
• CHECK_PROGS: Generic Programs
• CHECK_SIZEOF: C Compiler Characteristics
• CHECK_TOOL: Generic Programs
• CHECK_TYPE: Generic Typedefs
• CHECKING: Printing Messages
• COMPILE_CHECK: Examining Libraries
• CONFIG_AUX_DIR: Input
• CONFIG_HEADER: Configuration Headers
• CONFIG_SUBDIRS: Subdirectories
• CONST: Old Macro Names
• CROSS_CHECK: Old Macro Names
• CYGWIN: System Services
• DECL_SYS_SIGLIST: Particular Headers
• DECL_YYTEXT: Particular Programs
• DEFINE: Defining Symbols
• DEFINE_UNQUOTED: Defining Symbols
• DEFUN: Macro Definitions
• DIR_HEADER: Particular Headers
• DYNIX_SEQ: UNIX Variants
• EGREP_CPP: Examining Declarations
• EGREP_HEADER: Examining Declarations
• ENABLE: Package Options
• ERROR: Old Macro Names
• EXEEXT: System Services
• F77_LIBRARY_LDFLAGS: Fortran 77 Compiler Characteristics
• FIND_X: Old Macro Names
• FIND_XTRA: Old Macro Names
• FUNC_ALLOCA: Particular Functions
• FUNC_CHECK: Old Macro Names
• FUNC_CLOSEDIR_VOID: Particular Functions
• FUNC_FNMATCH: Particular Functions
• FUNC_GETLOADAVG: Particular Functions
• FUNC_GETMNTENT: Particular Functions
• FUNC_GETPGRP: Particular Functions
• FUNC_MEMCMP: Particular Functions
• FUNC_MMAP: Particular Functions
• FUNC_SELECT_ARGTYPES: Particular Functions
• FUNC_SETPGRP: Particular Functions
• FUNC_SETVBUF_REVERSED: Particular Functions
• FUNC_STRCOLL: Particular Functions
• FUNC_STRFTIME: Particular Functions
• FUNC_UTIME_NULL: Particular Functions
• FUNC_VFORK: Particular Functions
• FUNC_VPRINTF: Particular Functions
• FUNC_WAIT3: Particular Functions
• GCC_TRADITIONAL: Old Macro Names
• GETGROUPS_T: Old Macro Names
• GETLOADAVG: Old Macro Names
• HAVE_FUNCS: Old Macro Names
• HAVE_HEADERS: Old Macro Names
• HAVE_LIBRARY: Libraries
• HAVE_POUNDBANG: Old Macro Names
• HEADER_CHECK: Old Macro Names
• HEADER_DIRENT: Particular Headers
• HEADER_EGREP: Old Macro Names
• HEADER_MAJOR: Particular Headers
• HEADER_STAT: Structures
• HEADER_STDC: Particular Headers
• HEADER_SYS_WAIT: Particular Headers
• HEADER_TIME: Structures
• INIT: Input
• INLINE: Old Macro Names
• INT_16_BITS: C Compiler Characteristics
• IRIX_SUN: UNIX Variants
• ISC_POSIX: UNIX Variants
• LANG_C: Language Choice
• LANG_CPLUSPLUS: Language Choice
• LANG_FORTRAN77: Language Choice
• LANG_RESTORE: Language Choice
• LANG_SAVE: Language Choice
• LINK_FILES: Using System Type
• LN_S: Old Macro Names
• LONG_64_BITS: C Compiler Characteristics
• LONG_DOUBLE: Old Macro Names
• LONG_FILE_NAMES: Old Macro Names
• MAJOR_HEADER: Old Macro Names
• MEMORY_H: Particular Headers
• MINGW32: System Services
• MINIX: UNIX Variants
• MINUS_C_MINUS_O: Old Macro Names
• MMAP: Old Macro Names
• MODE_T: Old Macro Names
• MSG_CHECKING: Printing Messages
• MSG_ERROR: Printing Messages
• MSG_RESULT: Printing Messages
• MSG_WARN: Printing Messages
• OBJEXT: System Services
• OBSOLETE: Obsolete Macros
• OFF_T: Old Macro Names
• OUTPUT: Output
• PATH_PROG: Generic Programs
• PATH_PROGS: Generic Programs
• PATH_X: System Services
• PATH_XTRA: System Services
• PID_T: Old Macro Names
• PREFIX: Old Macro Names
• PREFIX_PROGRAM: Default Prefix
• PREREQ: Versions
• PROG_AWK: Particular Programs
• PROG_CC: Particular Programs
• PROG_CC_C_O: Particular Programs
• PROG_CPP: Particular Programs
• PROG_CXX: Particular Programs
• PROG_CXXCPP: Particular Programs
• PROG_F77_C_O: Particular Programs
• PROG_FORTRAN: Particular Programs
• PROG_GCC_TRADITIONAL: Particular Programs
• PROG_INSTALL: Particular Programs
• PROG_LEX: Particular Programs
• PROG_LN_S: Particular Programs
• PROG_MAKE_SET: Output
• PROG_RANLIB: Particular Programs
• PROG_YACC: Particular Programs
• PROGRAM_CHECK: Old Macro Names
• PROGRAM_EGREP: Old Macro Names
• PROGRAM_PATH: Old Macro Names
• PROGRAMS_CHECK: Old Macro Names
• PROGRAMS_PATH: Old Macro Names
• PROVIDE: Prerequisite Macros
• REMOTE_TAPE: Old Macro Names
• REPLACE_FUNCS: Generic Functions
• REQUIRE: Prerequisite Macros
• REQUIRE_CPP: Language Choice
• RESTARTABLE_SYSCALLS: Old Macro Names
• RETSIGTYPE: Old Macro Names
• REVISION: Versions
• RSH: Old Macro Names
• SCO_INTL: UNIX Variants
• SEARCH_LIBS: Libraries
• SET_MAKE: Old Macro Names
• SETVBUF_REVERSED: Old Macro Names
• SIZE_T: Old Macro Names
• SIZEOF_TYPE: Old Macro Names
• ST_BLKSIZE: Old Macro Names
• ST_BLOCKS: Old Macro Names
• ST_RDEV: Old Macro Names
• STAT_MACROS_BROKEN: Old Macro Names, Structures
• STDC_HEADERS: Old Macro Names
• STRCOLL: Old Macro Names
• STRUCT_ST_BLKSIZE: Structures
• STRUCT_ST_BLOCKS: Structures
• STRUCT_ST_RDEV: Structures
• STRUCT_TIMEZONE: Structures
• STRUCT_TM: Structures
• SUBST: Setting Output Variables
• SUBST_FILE: Setting Output Variables
• SYS_INTERPRETER: System Services
• SYS_LONG_FILE_NAMES: System Services
• SYS_RESTARTABLE_SYSCALLS: System Services
• SYS_SIGLIST_DECLARED: Old Macro Names
• TEST_CPP: Old Macro Names
• TEST_PROGRAM: Old Macro Names
• TIME_WITH_SYS_TIME: Old Macro Names
• TIMEZONE: Old Macro Names
• TRY_COMPILE: Examining Syntax
• TRY_CPP: Examining Declarations
• TRY_LINK: Examining Libraries
• TRY_LINK_FUNC: Examining Libraries
• TRY_RUN: Test Programs
• TYPE_GETGROUPS: Particular Typedefs
• TYPE_MODE_T: Particular Typedefs
• TYPE_OFF_T: Particular Typedefs
• TYPE_PID_T: Particular Typedefs
• TYPE_SIGNAL: Particular Typedefs
• TYPE_SIZE_T: Particular Typedefs
• TYPE_UID_T: Particular Typedefs
• UID_T: Old Macro Names
• UNISTD_H: Particular Headers
• USG: Particular Headers
• UTIME_NULL: Old Macro Names
• VALIDATE_CACHED_SYSTEM_TUPLE: Canonicalizing
• VERBOSE: Printing Messages
• VFORK: Old Macro Names
• VPRINTF: Old Macro Names
• WAIT3: Old Macro Names
• WARN: Old Macro Names
• WITH: External Software
• WORDS_BIGENDIAN: Old Macro Names
• XENIX_DIR: UNIX Variants
• YYTEXT_POINTER: Old Macro Names