Go to the first, previous, next, last section, table of contents.


時代遅れの構成物

Autoconfは変化し,歳月を経て時代遅れになった構成物もあります.変更のほ とんどはマクロの呼び出しですが,状況によっては,ツール自身やそのコンセ プトさえも,今では時代遅れと考えられるものもあります.

新しいAutoconfを使用する場合は,この章を完全に飛ばしてもかまいません. ここでの目的は主に,より新しい構成物に変更する方法を理解することで,パッ ケージを更新している管理者を助けることです.

時代遅れの`config.status'の呼び出し

`config.status'は現在,実際に作成されるファイルを指定するための引 数をサポートしています.詳細は,section コンフィグレーションの再生成を参照し てください.以前は環境変数の使用が必要でした.

Variable: CONFIG_COMMANDS
実行するコマンドのタグです.デフォルトは,`configure.ac'内の AC_OUTPUTAC_CONFIG_COMMANDSに与える引数です.

Variable: CONFIG_FILES
`@variable@'の置換を実行するファイルです.デフォルトは, `configure.ac'内のAC_OUTPUTAC_CONFIG_COMMANDSに与 える引数です.

Variable: CONFIG_HEADERS
Cの#define文の置換を行なうファイルです.デフォルトは AC_CONFIG_HEADERSに与える引数です.そのマクロが呼び出されていな い場合,`config.status'はこの値を無視します.

Variable: CONFIG_LINKS
作成されるシンボリックリンクです.デフォルトは,AC_CONFIG_LINKS に与える引数です.そのマクロが呼び出されていない場合, `config.status'はこの値を無視します.

section コンフィグレーションの再生成で古いインターフェースを使用する例は,以 下のようになります.

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

Makefile: Makefile.in config.status
        CONFIG_COMMANDS= CONFIG_LINKS= CONFIG_HEADERS= \
          CONFIG_FILES=Makefile ./config.status

(`configure.ac'AC_CONFIG_HEADERSを呼び出さない場合, makeルールにCONFIG_HEADERSを設定する必要はありません. CONFIG_COMMANDS等に対しても同様です.)

`acconfig.h'

`config.h.in'を生成するため,@command{autoheader}はそれぞれのシン ボルに対するテンプレートを構築したり探したりする必要がありました.現在 のAutoconfのリリースでは,AH_VERBATIMAH_TEMPLATEを使用 しますが(see section autoheaderのマクロ),古いリリースでは,ファイル `acconfig.h'に必要なテンプレートのリストを含めていました. @command{autoheader}は,コメントと#define#undefの文を, `acconfig.h' がカレントディレクトリに存在する場合はそこからコピー します.追加のシンボルをAC_DEFINEする場合,このファイルを使用す る必要がありました.

`config.h.in'に情報を前置/後置したい場合,現在のAutoconfのリリー スでも,AH_TOPAH_BOTTOMを提供しています.昔のバージョ ンのAutoconfにはよく似た機能がありました.`./acconfig.h'に文字列 `@TOP@'が含まれている場合,@command{autoheader}は`@TOP@' が含まれている行の前の行を生成するファイルの先頭にコピーします.同様に, `./acconfig.h'に文字列`@BOTTOM@'が含まれている場合, @command{autoheader}はその行の後の行を生成するファイルの末尾にコピーし ます.これらの文字列のいずれかまたは両方とも省略できます.古いバージョ ンのAutoconfで同じ効果を生成するための,さらに古い代替方法は,カレント ディレクトリにファイル`file.top'(通常は`config.h.top') や`file.bot'を作成することです.それらが存在する場合, @command{autoheader}はその出力の最初と終りに,それぞれその内容をコピー します.

以前のバージョンのAutoconfでは,配布するソフトウエアパッケージの準備で 使用するファイルは以下のようになっています.

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

AH_マクロだけを使用する際は,`configure.ac'は自己内蔵型に すべきで,そして,`acconfig.h'等に依存すべきではありません.

`configure.ac'を現代風にするために@command{autoupdate}を使用する

@command{autoupdate}プログラムは,Autoconfマクロを古い名前で呼び出して いる`configure.ac'ファイルを,現在のマクロ名に更新します.バージョ ン2のAutoconfでは,ほとんどのマクロが,より一様で記述的な命名法で名前 が変更されています.新しい方法の記述はSee section マクロ名. 古い名前も動 作しますが(古いマクロとそれに対応する新しいマクロのリストは see section 時代遅れのマクロ),新しいマクロ名を使用するために更新した場合, `configure.ac'はより可読性の高いものになり,現在のAutoconfマクロ を使用することがより簡単になります.

引数が与えられていない場合,@command{autoupdate}は`configure.ac' を更新し,元のバージョンを接尾子`~'でバックアップします(または, 環境変数SIMPLE_BACKUP_SUFFIXが設定されている場合はその値になり ます).@command{autoupdate}に引数を与えた場合,`configure.ac'の代 わりにそのファイルを読み込み,更新されたファイルを標準出力に出力します.

@command{autoupdate}は以下のオプションを受け入れます.

@option{--help}
@option{-h}
コマンドラインオプションの概要を出力して終了します.
@option{--version}
@option{-V}
Autoconfのバージョンナンバーを出力して終了します.
@option{--verbose}
@option{-v}
処理している段階を報告します.
@option{--debug}
@option{-d}
一時的なファイルを削除しません.
@option{--force}
@option{-f}
ファイルが変更されていない場合でも強制的に更新します.キャッシュは無視 されます.
@option{--include=dir}
@option{-I dir}
入力ファイルをdirでも探します.複数回の呼び出しは累積されます. ディレクトリは最後のものから最初のものという順序で見ていきます.

時代遅れのマクロ

様々な理由で(通常適切に引用婦で囲むことに失敗していて以前の配布物が拡 張できないなどの理由です),いくつかのマクロがAutoconfで時代遅れになっ ています.それらはサポートされていますが,使用を止めるようお願いします. それらの使用は避けた方が良いでしょう.

Autoconfのバージョン1からバージョン2へ移行している間,より一般的でより 記述的な命名法を使用するために,ほとんどのマクロの名前が変更されました が,そのシグニチャは変更されていません.以下で,これらのマクロの古い名 前と新しい名前の対応付けがあるものは,署名と記述に対する新しいマクロの 定義へ参照するよう読者を招待します.

Macro: AC_ALLOCA
AC_FUNC_ALLOCA

Macro: AC_ARG_ARRAY
有用性の制限のため削除.

Macro: AC_C_CROSS
このマクロは時代遅れです.何もしません.

Macro: AC_CANONICAL_SYSTEM
システムタイプを決定し,出力変数を標準的なシステムタイプ名に設定します. このマクロが設定する変数の詳細はSee section 標準的なシステムタイプの取得.

ユーザは必要なものに依存して,AC_CANONICAL_BUILDまたは AC_CANONICAL_HOSTのいずれか,またはAC_CANONICAL_TARGETを 使用することを推奨します.AC_CANONICAL_TARGETを実行することで, 必ずそれ以外の二つのマクロが実行されます.

Macro: AC_CHAR_UNSIGNED
AC_C_CHAR_UNSIGNED

Macro: AC_CHECK_TYPE (type, default)
2.13までのAutoconfでは,このバージョンのAC_CHECK_TYPEを提供する ために使用されていましたが,問題があり反対されていました.第一に,それ はCHECK一族のメンバーですが,単一のファミリーに過ぎず,調査以上 のことを行なっていました.次に,足りない型はtypedefされず,それ らは#defineされるので,ポインタ型の場合は互換性がなくなってしま うはずです.

このAC_CHECK_TYPEの使用は時代遅れで推奨できません.現在のマクロ の記述は,section 一般的な型の調査を参照してください.

typeが定義されていない場合,それはC(またはC++)の組み込みの型 defaultに定義されます.例えば,`short'`unsigned'です.

このマクロは以下と等価です.

AC_CHECK_TYPE([type],,
              [AC_DEFINE_UNQUOTED([type], [default],
                                  [Define to `default' if
                                   <sys/types.h> does not define.])])

下位互換性のため,二つのバージョンのAC_CHECK_TYPEが実装されてい て,単純な発見的手法で選択されます.

  1. 引数が三つまたは四つある場合,現在のバージョンが使用されます.
  2. 二番目の引数にCやC++の型がある場合,時代遅れのバージョンが使用されます. 引数がCやC++に組み込まれている型,または`_t'で終るC識別子 で,さらに一つの`[(* 'が続き,その後にゼロ以上の`[]()* _a-zA-Z0-9'以外の文字列が続く場合はこうなります.
  3. 二番目の引数が有効なCとC++のアルファベットで綴られている型の場合,ユー ザは警告され,現在のバージョンが使用されます.
  4. それ以外では,現在のバージョンが使用されます.

有効な組み込みの型を使用する,または,同じ現在のコード(上記参照)を使用 する,もしくはそれより良いものとして,AC_CHECK_TYPESとともに使 用することをお勧めします.

#if !HAVE_LOFF_T
typedef loff_t off_t;
#endif

Macro: AC_CHECKING (feature-description)
`AC_MSG_NOTICE([checking feature-description...]'と同じ です.

Macro: AC_COMPILE_CHECK (echo-text, includes, function-body, action-if-found, @ovar{action-if-not-found})
これは,AC_TRY_COMPILEの時代遅れのバージョンで,それ自身も AC_COMPILE_IFELSEで置換され(see section コンパイラの実行),それ はecho-textが空ではない場合,`checking for echo-text' を標準出力の最初に追加出力します.メッセージを出力するためには,代わり にAC_MSG_CHECKINGAC_MSG_RESULTを使用してください (see section メッセージの出力).

Macro: AC_CONST
AC_C_CONST

Macro: AC_CROSS_CHECK
AC_C_CROSSと同じで,さらにそれも時代遅れになっていて,何もしま せん:-)

Macro: AC_CYGWIN
Cygwin環境を調査し,その状況ではシェル変数CYGWIN`yes'に 設定します.このマクロを使用せず,権威のあるホストの調査手法 AC_CANONICAL_HOSTが使用されています.実際問題として,このマクロ は以下のように定義されています.
AC_REQUIRE([AC_CANONICAL_HOST])[]dnl
case $host_os in
  *cygwin* ) CYGWIN=yes;;
         * ) CYGWIN=no;;
esac

変数CYGWINには,CygWin32を実行しているときは非常に特殊な意味が あることに注意し,変更すべきではありません.それはこのマクロを使用しな いもう一つの理由です.

Macro: AC_DECL_SYS_SIGLIST
`AC_CHECK_DECLS([sys_siglist])'と同じです.

Macro: AC_DECL_YYTEXT
何もせず,現在はAC_PROG_LEXに統合されています.

Macro: AC_DIR_HEADER
AC_FUNC_CLOSEDIR_VOIDAC_HEADER_DIRENTの呼び出しに似て いますが,ヘッダファイルが見つかったことを示すため,異なるCプリプロセッ サマクロの組を定義します.
  • ヘッダ 古いシンボル 新しいシンボル
  • `dirent.h' DIRENT HAVE_DIRENT_H
  • `sys/ndir.h' SYSNDIR HAVE_SYS_NDIR_H
  • `sys/dir.h' SYSDIR HAVE_SYS_DIR_H
  • `ndir.h' NDIR HAVE_NDIR_H
  • Macro: AC_DYNIX_SEQ
    DYNIX/ptxの場合,出力変数LIBSに@option{-lseq} を追加します.こ のマクロは以下のように定義されるように使用されていました.
    AC_CHECK_LIB(seq, getmntent, LIBS="-lseq $LIBS")
    
    現在では,AC_FUNC_GETMNTENTで行ないます.
    Macro: AC_EXEEXT
    コンパイラの出力を元に出力変数EXEEXTを定義し,それは現在では自 動的に行なわれます.通常,Unixでは空の文字列で,Win32やOS/2では `.exe' に設定します.
    Macro: AC_EMXOS2
    AC_CYGWINに似ていますが,OS/2のEMX環境変数を調査しEMXOS2 を設定します.
    Macro: AC_ERROR
    AC_MSG_ERROR
    Macro: AC_FIND_X
    AC_PATH_X
    Macro: AC_FIND_XTRA
    AC_PATH_XTRA
    Macro: AC_FUNC_CHECK
    AC_CHECK_FUNC
    Macro: AC_FUNC_WAIT3
    wait3が見つかり,第三引数(`struct rusage *')の内容が満たさ れている場合,HP-UXは違いますが,HAVE_WAIT3を定義します. 現在では,wait3はOpen Groupの標準から削除されていて,次のリビジョ ンの@acronym{POSIX}では無くなるので,移植性の高いプログラムでは wait3ではなくwaitpidを使用すべきです.
    Macro: AC_GCC_TRADITIONAL
    AC_PROG_GCC_TRADITIONAL
    Macro: AC_GETGROUPS_T
    AC_TYPE_GETGROUPS
    Macro: AC_GETLOADAVG
    AC_FUNC_GETLOADAVG
    Macro: AC_HAVE_FUNCS
    AC_CHECK_FUNCS
    Macro: AC_HAVE_HEADERS
    AC_CHECK_HEADERS
    Macro: AC_HAVE_LIBRARY (library, @ovar{action-if-found}, @ovar{action-if-not-found}, @ovar{other-libraries})
    このマクロは,function引数をmainにしたAC_CHECK_LIB の呼び出しと同じです.さらに,libraryは,`foo', @option{-lfoo},または`libfoo.a'のいずれで書くことも可能です.こ れら全ての状況で,コンパイラに@option{-lfoo}が渡されます.しかし, libraryをシェル変数することは不可能です.リテラル名にする必要が あります.
    Macro: AC_HAVE_POUNDBANG
    AC_SYS_INTERPRETER (呼び出し規則が異なります)
    Macro: AC_HEADER_CHECK
    AC_CHECK_HEADER
    Macro: AC_HEADER_EGREP
    AC_EGREP_HEADER
    Macro: AC_INIT (unique-file-in-source-dir)
    以前のAC_INITは単一の引数のみで使用され,それは以下と同じです.
    AC_INIT
    AC_CONFIG_SRCDIR(unique-file-in-source-dir)
    
    Macro: AC_INLINE
    AC_C_INLINE
    Macro: AC_INT_16_BITS
    Cの型intが16ビット幅の場合,INT_16_BITSを定義します.代 わりに`AC_CHECK_SIZEOF(int)'を使用してください.
    Macro: AC_IRIX_SUN
    @acronym{AIX} (Silicon Graphics UNIX)の場合,出力変数LIBS に@option{-lsun}を追加します.getmntentを取得するためにそれを使 用している場合,その代わりにAC_FUNC_GETMNTENTを使用してください. NIS バージョンのパスワードとグループ関数のためにそれを使用している場合. `AC_CHECK_LIB(sun, getpwnam)'を使用してください.Autoconf 2.13ま では,以下のように使用されていました.
    AC_CHECK_LIB(sun, getmntent, LIBS="-lsun $LIBS")
    
    現在ではそれは以下のように定義されます.
    AC_FUNC_GETMNTENT
    AC_CHECK_LIB(sun, getpwnam)
    
    Macro: AC_LANG_C
    `AC_LANG(C)'と同じです.
    Macro: AC_LANG_CPLUSPLUS
    `AC_LANG(C++)'と同じです.
    Macro: AC_LANG_FORTRAN77
    `AC_LANG(Fortran 77)'と同じです.
    Macro: AC_LANG_RESTORE
    AC_LANG_SAVEで設定されるように,スタックのトップに保存される languageを選択し,スタックから削除し, AC_LANG(language)を呼び出します.
    Macro: AC_LANG_SAVE
    現在の言語を(AC_LANGで設定されるように)スタックに記憶します.現 在の言語は変更されません.AC_LANG_PUSHが好まれます.
    Macro: AC_LINK_FILES (source..., dest...)
    これは,AC_CONFIG_LINKSの時代遅れのバージョンです.以下を更新し たバージョンにします.
    AC_LINK_FILES(config/$machine.h config/$obj_format.h,
                  host.h            object.h)
    
    それは,以下のようになります.
    AC_CONFIG_LINKS(host.h:config/$machine.h
                    object.h:config/$obj_format.h)
    
    Macro: AC_LN_S
    AC_PROG_LN_S
    Macro: AC_LONG_64_BITS
    Cの型long intが64ビット幅の場合,LONG_64_BITSを定義しま す.その代わりに,一般的なマクロ`AC_CHECK_SIZEOF([long int])'を使 用してください.
    Macro: AC_LONG_DOUBLE
    AC_C_LONG_DOUBLE
    Macro: AC_LONG_FILE_NAMES
    AC_SYS_LONG_FILE_NAMES
    Macro: AC_MAJOR_HEADER
    AC_HEADER_MAJOR
    Macro: AC_MEMORY_H
    mem関数が`memory.h'で定義されている場合に NEED_MEMORY_Hを定義するために使用されます.現在は, `AC_CHECK_HEADERS(memory.h)'と同じです.コードを NEED_MEMORY_HではなくHAVE_MEMORY_Hに依存するように調整し てください.See section 標準的なシンボル.
    Macro: AC_MINGW32
    AC_CYGWINに似ていますが,それはMingW32コンパイラの環境を調査し MINGW32を設定します.
    Macro: AC_MINUS_C_MINUS_O
    AC_PROG_CC_C_O
    Macro: AC_MMAP
    AC_FUNC_MMAP
    Macro: AC_MODE_T
    AC_TYPE_MODE_T
    Macro: AC_OBJEXT
    `.c'ファイルが除外された後,コンパイラの出力に基づいて,出力変数 OBJEXTを定義します.通常,Unixでは`o'で,Win32では `obj'に設定します.現在はコンパイラの調査マクロがこれを自動的に処 理します.
    Macro: AC_OBSOLETE (this-macro-name, @ovar{suggestion})
    M4が標準エラー出力に,this-macro-nameが時代遅れだというメッセー ジをそれが呼び出されているファイルと行とともに出力します. this-macro-nameは,AC_OBSOLETEが呼び出しているマクロ名に すべきです.suggestionが与えられている場合,それは警告メッセージ の終りに出力されます.例えば,this-macro-nameの代わりに使用する ものを提案することが可能になります. 例えば以下のようにします.
    AC_OBSOLETE([$0], [; use AC_CHECK_HEADERS(unistd.h) instead])dnl
    
    ユーザに対するより良いサービスとなるので,代わりにAU_DEFUNを使 用することを推奨します.
    Macro: AC_OFF_T
    AC_TYPE_OFF_T
    Macro: AC_OUTPUT (@ovar{file}..., @ovar{extra-cmds}, @ovar{init-cmds})
    引数を用いたAC_OUTPUTの使用は反対されます.これは以下と同じもの の時代遅れのインターフェースです.
    AC_CONFIG_FILES(file...)
    AC_CONFIG_COMMANDS([default],
                       extra-cmds, init-cmds)
    AC_OUTPUT
    
    Macro: AC_OUTPUT_COMMANDS (extra-cmds, @ovar{init-cmds})
    `config.status'の終りに実行する追加のシェルコマンドと, @command{configure}で変数を初期化するためのシェルコマンドをを指定しま す.このマクロは複数回呼び出し可能です.それは時代遅れで, AC_CONFIG_COMMANDSで置換されました. 以下は現実的ではない例です.
    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])
    
    AC_CONFIG_COMMANDSが追加のキーを要求する事実以外,重要な差は AC_OUTPUT_COMMANDSが引数を二回引用符で囲んでいますが AC_CONFIG_COMMANDSはそうではないということです.これは, AC_CONFIG_COMMANDSでは引数を用いてマクロを安全に呼び出すことが 可能だということを意味します.
    AC_CONFIG_COMMANDS(foo, [my_FOO()])
    
    反対に,1レベルの引用符がAC_OUTPUT_COMMANDSでのリテラル文字列に 対して十分なところでは,AC_CONFIG_COMMANDSが二回必要になります. 以下の行は等価です.
    AC_OUTPUT_COMMANDS([echo "Square brackets: []"])
    AC_CONFIG_COMMANDS([default], [[echo "Square brackets: []"]])
    
    Macro: AC_PID_T
    AC_TYPE_PID_T
    Macro: AC_PREFIX
    AC_PREFIX_PROGRAM
    Macro: AC_PROG_CC_STDC
    このマクロは,AC_PROG_CCに統合されました.
    Macro: AC_PROGRAMS_CHECK
    AC_CHECK_PROGS
    Macro: AC_PROGRAMS_PATH
    AC_PATH_PROGS
    Macro: AC_PROGRAM_CHECK
    AC_CHECK_PROG
    Macro: AC_PROGRAM_EGREP
    AC_EGREP_CPP
    Macro: AC_PROGRAM_PATH
    AC_PATH_PROG
    Macro: AC_REMOTE_TAPE
    有用性の制限のため削除されました.
    Macro: AC_RESTARTABLE_SYSCALLS
    AC_SYS_RESTARTABLE_SYSCALLS
    Macro: AC_RETSIGTYPE
    AC_TYPE_SIGNAL
    Macro: AC_RSH
    有用性の制限のため削除されました.
    Macro: AC_SCO_INTL
    SCO UNIXの場合,出力変数LIBSに@option{-lintl}を加えます.このマ クロは以下を使用していました.
    AC_CHECK_LIB(intl, strftime, LIBS="-lintl $LIBS")
    
    現在は,代わりにAC_FUNC_STRFTIMEを呼び出します.
    Macro: AC_SETVBUF_REVERSED
    AC_FUNC_SETVBUF_REVERSED
    Macro: AC_SET_MAKE
    AC_PROG_MAKE_SET
    Macro: AC_SIZEOF_TYPE
    AC_CHECK_SIZEOF
    Macro: AC_SIZE_T
    AC_TYPE_SIZE_T
    Macro: AC_STAT_MACROS_BROKEN
    AC_HEADER_STAT
    Macro: AC_STDC_HEADERS
    AC_HEADER_STDC
    Macro: AC_STRCOLL
    AC_FUNC_STRCOLL
    Macro: AC_ST_BLKSIZE
    AC_CHECK_MEMBERS
    Macro: AC_ST_BLOCKS
    AC_STRUCT_ST_BLOCKS
    Macro: AC_ST_RDEV
    AC_CHECK_MEMBERS
    Macro: AC_SYS_RESTARTABLE_SYSCALLS
    システムが自動的にシグナルで中断されたシステムコールを再スタートする場 合,HAVE_RESTARTABLE_SYSCALLSを定義します.このマクロは,システ ムが一般的に再スタートするかどうかを調査しません -- それは, (sigactionではなく)signalでインストールされているシグナ ルハンドラが再スタートするためのシステムコールを呼び出すかどうかをテス トします.ハンドラの無いシグナルで中断されたときにシステムコールが再ス タートされる場合,テストしません. 今日の移植性の高いプログラムでは,システムコールを再スタートしたい場合, SA_RESTARTを用いてsigactionを使用すべきです.現在では, システムコールが再スタート可能かどうかは,コンフィグレーション時の問題 ではなく動的な問題なので,HAVE_RESTARTABLE_SYSCALLSに依存すべき ではありません.
    Macro: AC_SYS_SIGLIST_DECLARED
    AC_DECL_SYS_SIGLIST
    Macro: AC_TEST_CPP
    AC_TRY_CPPになり,それもAC_PREPROC_IFELSEで置き換えられ ました.
    Macro: AC_TEST_PROGRAM
    AC_TRY_RUNになり,それもAC_RUN_IFELSEで置き換えられまし た.
    Macro: AC_TIMEZONE
    AC_STRUCT_TIMEZONE
    Macro: AC_TIME_WITH_SYS_TIME
    AC_HEADER_TIME
    Macro: AC_TRY_COMPILE (includes, function-body, @ovar{action-if-found}, @ovar{action-if-not-found})
    `AC_COMPILE_IFELSE([AC_LANG_SOURCE([[includes]], [[function-body]])], [action-if-true], [action-if-false])'と同じです(see section コンパイラの実行). このマクロは,includesfunction-bodyの両方を二重に引用符 で囲みます. CとC++に対して,includesfunction-bodyにあるコードが必要 とするすべての#include文です(現在選択されている言語がFortran 77 の場合,includesは無視されます).このマクロは,CやC++のいずれか が現在選択されている言語になっている場合,CFLAGSCXXFLAGSを使用し,コンパイル時には同様にCPPFLAGSを使用し ます.Fortran 77が現在選択されている言語の場合,FFLAGSがコンパ イルで使用されるでしょう.
    Macro: AC_TRY_CPP (input, @ovar{action-if-true}, @ovar{action-if-false})
    `AC_PREPROC_IFELSE([AC_LANG_SOURCE([[input]])], [action-if-true], [action-if-false])'と同じです (see section プリプロセッサの実行). このマクロはinputを二重に引用符で囲みます.
    Macro: AC_TRY_LINK (includes, function-body, @ovar{action-if-found}, @ovar{action-if-not-found})
    `AC_LINK_IFELSE([AC_LANG_SOURCE([[includes]], [[function-body]])], [action-if-true], [action-if-false])'と同じです(see section コンパイラの実行). このマクロは,includesfunction-bodyの両方を二重に引用符 で囲みます. 現在の言語に依存して(see section 言語の選択),function-bodyの中 身にある関数をコンパイルしリンクすることが可能かどうかを調べるテストプ ログラムを作成します.ファイルのコンパイルとリンクが成功する場合,シェ ルコマンドaction-if-foundを実行し,それ以外では action-if-not-foundを実行します. このマクロは,includesfunction-bodyの両方を二重に引用符 で囲みます. CとC++に対して,includesfunction-bodyにあるコードが必要 とするすべての#include文です(現在選択されている言語がFortran 77 の場合,includesは無視されます).このマクロは,CやC++のいずれか が現在選択されている言語になっている場合,CFLAGSCXXFLAGSを使用し,コンパイル時には同様にCPPFLAGSを使用し ます.Fortran 77が現在選択されている言語の場合,FFLAGSがコンパ イルで使用されるでしょう.しかし,LDFLAGSLIBSは,あら ゆる状況でリンク時に使用されます.
    Macro: AC_TRY_LINK_FUNC (function, @ovar{action-if-found}, @ovar{action-if-not-found})
    このマクロは,`AC_LINK_IFELSE([AC_LANG_CALL([[includes]], [[function-body]])], [action-if-true], [action-if-false])'と同じです.
    Macro: AC_TRY_RUN (program, @ovar{action-if-true}, @ovar{action-if-false}, @ovar{action-if-cross-compiling})
    `AC_RUN_IFELSE([AC_LANG_SOURCE([[program]], [action-if-true], [action-if-false], [action-if-cross-compiling])'と同じです(see section 実行時の動作の調査).
    Macro: AC_UID_T
    AC_TYPE_UID_T
    Macro: AC_UNISTD_H
    `AC_CHECK_HEADERS(unistd.h)'と同じです.
    Macro: AC_USG
    @acronym{BSD}文字列関数が`strings.h'で定義されている場合, USGを定義します.これからはUSGではなく HAVE_STRING_Hに依存するようにすべきです.See section 標準的なシンボル.
    Macro: AC_UTIME_NULL
    AC_FUNC_UTIME_NULL
    Macro: AC_VALIDATE_CACHED_SYSTEM_TUPLE (@ovar{cmd})
    キャッシュファイルが現在のホスト,ターゲット,そしてビルドシステムのタ イプで矛盾がある場合,cmdを実行したりデフォルトのエラーメッセー ジを出力したりするために使用されていました.これは現在デフォルトで処理 されます.
    Macro: AC_VERBOSE (result-description)
    AC_MSG_RESULT.
    Macro: AC_VFORK
    AC_FUNC_VFORK
    Macro: AC_VPRINTF
    AC_FUNC_VPRINTF
    Macro: AC_WAIT3
    AC_FUNC_WAIT3
    Macro: AC_WARN
    AC_MSG_WARN
    Macro: AC_WORDS_BIGENDIAN
    AC_C_BIGENDIAN
    Macro: AC_XENIX_DIR
    このマクロは,Xenixの場合に出力変数LIBSに@option{-lx}を追加する ために使用されていました.また,`dirent.h'が調査され,LIBS を@option{-ldir}に追加していました.現在では,AC_HEADER_DIRENT の代わりの別名となっていることも滅多に無く,依存すべきではありませんが, XENIXで実行されているかどうかを検出するコートが追加されています.
    AC_MSG_CHECKING([for Xenix])
    AC_EGREP_CPP(yes,
    [#if defined M_XENIX && !defined M_UNIX
      yes
    #endif],
                 [AC_MSG_RESULT([yes]); XENIX=yes],
                 [AC_MSG_RESULT([no]); XENIX=])
    
    Macro: AC_YYTEXT_POINTER
    AC_DECL_YYTEXT

    バージョン1からの更新

    Autoconfバージョン2は,バージョン1とほとんど下位互換性があります.しか し,何かをするときにより良くなる方法も導入していますし,バージョン1の 醜いものにはサポートしなくなったものもあります.そのため, `configure.ac'の洗練具合に依存して,バージョン2に更新するための手 作業が必要になります.この章は,更新時に見るべき問題点も示します.また, @command{configure}スクリプトは,バージョン2の新しい機能でより良くなり ます.変更点は,Autoconf配布物のファイル`NEWS'に概要が書かれてい ます.

    ファイル名の変更

    Autoconfでインストールされた`aclocal.m4'がある場合,(特定のパッケー ジのソースディレクトリと対立するので),それを`acsite.m4'に名前を 変更する必要があります.See section @command{configure}を作成するため@command{autoconf}を使用する.

    パッケージで`install.sh'を配布する場合,make組み込みルール が,`install'と呼ばれる意図しないファイルを作成するので, `install-sh'に名前を変更してください.AC_PROG_INSTALLは両 方の名前でスクリプトを探しますが,新しい名前を使用するのが最善です.

    `config.h.top'`config.h.bot',または`acconfig.h'を使 用している場合,そのまま使用することは可能ですが,AH_マクロを使 用するとバラバラになりません.See section autoheaderのマクロ.

    Makefileの変更

    `Makefile.in'ファイルに`@CFLAGS@'`@CPPFLAGS@',そ して`@LDFLAGS@'を,@command{configure}実行時に,環境変数として これらの変数の値を利用できるので,それらを加えてください.必要ではあり ませんが,ユーザにとって便利です.

    出力ファイルに,@command{configure}で生成されたというコメントを含める ために,AC_OUTPUTに対する`Makefile'以外の入力ファイルのそ れそれのコメントに,`@configure_input@'を加えてください. AC_OUTPUTで呼び出す全ての種類のファイルに対し,自動的に正しいコ メント文を選択するには,作業が非常に多くなります.

    distcleanターゲットで削除するファイルリストに, `config.log'`config.cache'を加えてください.

    以下のような`Makefile.in'がある場合を考えます.

    prefix = /usr/local
    exec_prefix = $(prefix)
    

    以下のように変更する必要があります.

    prefix = @prefix@
    exec_prefix = @exec_prefix@
    

    周りに`@'が無い変数の置換をする古い動作は削除されました.

    変更されたマクロ

    Autoconfバージョン2でマクロの多くは名前が変更されました.まだ古い名前 を使用することも可能ですが,新しいものはより明確で,それらのドキュメン トは簡単に見つかります.古いマクロに対する新しい名前の表は, See section 時代遅れのマクロ. 新しいマクロを使用するように `configure.ac'を変換するため,@command{autoupdate}プログラムを使 用してください.See section `configure.ac'を現代風にするために@command{autoupdate}を使用する.

    マクロには,より良い仕事をする似たものに置き換えられたものもありますが, 呼び出しに互換性がありません.@command{autoconf}実行中に,時代遅れのマ クロの呼び出しに関する警告がある場合,無視しても大丈夫ですが,時代遅れ のマクロの置換に関して出力されるアドバイスに従う場合, @command{configure}スクリプトはより良い仕事をします.特に,テストの結 果を報告するメカニズムが変化しました.(おそらくAC_COMPILE_CHECK によって)echoAC_VERBOSEを使用していた場合, @command{configure}スクリプトの出力は,AC_MSG_CHECKINGAC_MSG_RESULTに変えた方が良く見えるでしょう.See section メッセージの出力. これらのマクロは,キャッシュ変数に関連して最高の仕事をしま す.See section 結果のキャッシュ.

    変更された結果

    シェル変数のDEFSを調査することで,前のテストの結果を調査してい た場合,それらのテストに対するキャッシュ変数の値を調査することに切り替 える必要があります.DEFSは@command{configure}実行中にも存在しま せん.それは出力ファイルを生成するときのみ作成されます.バージョン1か らのこの違いは,正確にその変数を引用符で囲むことが,あまりに厄介で, AC_DEFINEを毎回呼び出すことは,非効率だと分かったためです. See section キャッシュ変数名.

    例えば,Autoconfバージョン1に対して書かれた,`configure.ac'の一部 は以下のようになります.

    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 -l$lib"; break])
      done
    fi
    

    引用符の前にバックスラッシュを加えることで,AC_DEFINE_UNQUOTED でバグが生じる場合,それを削除する必要があります.今は予想通りに動作し, (バックスラッシュ以外の)引用符を特別扱いしません.See section 出力変数の設定.

    現在,Autoconfマクロが設定した真偽値のシェル変数のすべては,真の値に対 して`yes'が使用され.偽に対してはほとんど`no'を使用しますが, 下位互換性のため,代わりに空の文字列を使用するものもあります.真に対し て1や`t'にシェル変数が設定されることを期待する場合,テストを変更 する必要があります.

    マクロの書き方の変更

    独自のマクロを定義するとき,現在はdefineの代わりに AC_DEFUNを使用すべきです.AC_DEFUNAC_PROVIDEを 自動的に呼び出し, AC_REQUIREのために呼び出されるマクロが,画面 上で入れ子状になっている`checking...'メッセージを妨げないよう に,他のマクロを中断していないことを確かめます.古い方法を使用し続けて も実際に害はありませんが,便利さと美しさが現象します.See section マクロの定義.

    恐らく,Autoconfと共にやってくるマクロを,何かをする方法のガイドとして 見ることになるでしょう.新しいバージョンのものを見ることは,スタイルが 改善されているものもあり,新しい機能も利用しているので,よい考えでしょ う.

    文書化されていないAutoconfの内部(マクロ,変数,変換)を使用して,トリッ キーなことをしていた場合,なされた変更を考慮するため,変更する必要があ るかどうか調査してください.恐らくkludeする代わりに,バージョン2で公式 にサポートされたテクニックを使用することができます.そうしなければダメ でしょう.

    ローカルで書かれた特徴のテストを高速化するため,キャッシュを加えてくだ さい.共有可能なマクロをカプセル化するため,テストが一般的に十分役に立 つことを確かめてください.

    バージョン2.13からの更新

    前のセクション(see section バージョン1からの更新)の導入は,このセクションにも全く適し ているなあ@enddots{}

    Autoconfバージョン2.50は,バージョン2.13とほとんど下位互換性があります. しかし,何かをするときより良くする方法も導入し,バージョン2.13の醜いも のにはサポートしなくなったものもあります.そのため, `configure.ac'の洗練具合に依存して,バージョン2.50に更新するため の手作業が必要になります.この章は,更新時に見るべき問題点も示します. また,@command{configure}スクリプトは,バージョン2.50の新しい機能でよ り良くなります.変更点は,Autoconf 配布物のファイル`NEWS'に概要が 書かれています.

    引用符で囲むことの変更

    紹介すべき最も重要な変更です.ほとんどのマクロの実装は完全に変更されま した.コードの分解,エラーメッセージの改善,ユーザインターフェースの一 貫性などが,このことで可能になりました.残念ながら副作用として,これま で(奇跡的に)動作していた構成物には,Autoconf 2.50でおかしくなり始める ものもあります.

    例えば,以下の例では,メッセージが適切に引用符で囲まれていません.

    AC_INIT
    AC_CHECK_HEADERS(foo.h,,
    AC_MSG_ERROR(cannot find foo.h, bailing out))
    AC_OUTPUT
    

    Autoconf 2.13は,単純にそれを無視していました.

    $ autoconf-2.13; ./configure --silent
    creating cache ./config.cache
    configure: error: cannot find foo.h
    $
    

    しかしAutoconf 2.50では,壊れた`configure'を生成します.

    $ autoconf-2.50; ./configure --silent
    configure: error: cannot find foo.h
    ./configure: exit: bad non-numeric arg `bailing'
    ./configure: exit: bad non-numeric arg `bailing'
    $
    

    メッセージは引用符で囲む必要があり,AC_MSG_ERRORの呼び出しもそ うです!

    AC_INIT
    AC_CHECK_HEADERS(foo.h,,
                     [AC_MSG_ERROR([cannot find foo.h, bailing out])])
    AC_OUTPUT
    

    多くの多くの(いくらでも続けたい)Autoconfマクロには...少なくとも AC_DEFUN自身も含めて,適切な引用がありませんでした!

    $ cat configure.in
    AC_DEFUN([AC_PROG_INSTALL],
    [# My own much better version
    ])
    AC_INIT
    AC_PROG_INSTALL
    AC_OUTPUT
    $ autoconf-2.13
    autoconf: Undefined macros:
    ***BUG in Autoconf--please report*** AC_FD_MSG
    ***BUG in Autoconf--please report*** AC_EPI
    configure.in:1:AC_DEFUN([AC_PROG_INSTALL],
    configure.in:5:AC_PROG_INSTALL
    $ autoconf-2.50
    $
    

    新しいマクロ

    Autoconfは何年も休止中だったので,その間AutomakeがAutoconfのようなマク ロを提供していました.現在は,Autoconf 2.50がこれらのマクロのより良い バージョンを提供していて,AM_ではなくAC_の名前空間で統合 されています.しかし,@command{autoupdate}で容易に更新できるように,そ のようなAM_マクロも結合されて提供されています.

    残念ながら,Automakeはこれらのマクロ名を引用符で囲んでいませんでした. そのため,@command{m4}が`AC_DEFUN(AM_TYPE_PTRDIFF_T, ...)'の ようなマクロを`aclocal.m4'で見つけたとき, AM_TYPE_PTRDIFF_Tは展開され,そのAutoconfの定義で置換されていま した.

    幸い,Autoconfは前置されるAC_INITの展開を受けて,それが所有する 単語で文句をいいます.

    $ cat configure.in
    AC_INIT
    AM_TYPE_PTRDIFF_T
    $ aclocal-1.4
    $ autoconf
    ./aclocal.m4:17: error: m4_defn: undefined macro: _m4_divert_diversion
    actypes.m4:289: AM_TYPE_PTRDIFF_T is expanded from...
    ./aclocal.m4:17: the top level
    $
    

    将来のAutomakeのバージョンは,単純にこれらのマクロをこれ以上定義せず, おそらく残りのマクロ名を引用符で囲むでしょう.しかし,全てがうまくいく までじっと待っている必要はありません.(単独で要求されるものもあります が)マクロを提供するための仕事は単純ではないので,Automakeのマクロに依 存しないでください.

    $ cat configure.in
    AC_INIT
    AM_TYPE_PTRDIFF_T
    $ rm aclocal.m4
    $ autoupdate
    autoupdate: `configure.in' is updated
    $ cat configure.in
    AC_INIT
    AC_CHECK_TYPES([ptrdiff_t])
    $ aclocal-1.4
    $ autoconf
    $
    

    ホストとクロスコンパイル

    コンパイラ作者の経験とそれ以降の長期にわたる公開討論を基にして,一連の クロスコンパイルの多くの面が変更されました.

    ビルド,ホスト,そしてターゲットアーキテクチャタイプの違いに関連するこ とは解決しています.一連のデフォルトは,現在は単純です.ターゲットのデ フォルトはホスト,ホストはビルド,そしてビルドは@command{config.guess} の結果となっています.それにもかかわらず,2.13から2.50へ容易に変換する ために,以下の変換手法が実装されています.それは,リリースの組を完全に 利用不可能にすることはできないので,それに依存しないでください (直すより問題が生じることが多いので,我々はそれを維持することは不可能 です).

    @option{--build}または@option{--host}で指定しない限り,すべてのデフォ ルトは@command{config.guess}の実行結果になります.指定する場合は,デフォ ルトは指定したシステムタイプになります.両方を指定していて異なっている 場合,テストと要求された実行物をの実行しないように, @command{configure}はクロスコンパイルモードになります.

    ヒント:@command{config.guess}の結果に優先させたい場合は, @option{--host}ではなく@option{--build}の方が好ましくなっています.将 来は,@option{--host}でビルドシステムタイプを優先しなくなるでしょう. --hostを指定する場合も,確実に--buildも指定してください.

    下位互換性のため,@command{configure}はシステムタイプ自身をオプション として受け入れます.そのようなオプションは,ビルド,ホスト,そしてター ゲットのシステムタイプのデフォルトに優先されます.以下のコンフィグレー ション命令では,Net@acronym{BSD}/alphaで実行するのですが,ビルドプラッ トフォームにもなる@acronym{GNU} Hurd/sparcのコードを生成する一連のクロ スツールがコンフィグレーションされます.

    ./configure --host=alpha-netbsd sparc-gnu
    

    Autoconf 2.13とそれ以前では,変数buildhost,そして targetは,AC_CANONICAL_BUILDの呼び出しの前後で異なる意味 を持っていました.現在は,@option{--build}の引数を指定することで,それ は厳密な意味でbuild_aliasにコピーされ,それ以外では空のままにな ります.AC_CANONICAL_BUILDの後で,buildは標準的なビルド タイプに設定されます.変換を容易にするため,以前の内容は, build_aliasと同じです.この壊れた機能に依存しないように してください.

    下位互換性を考慮した手法は上のようになり,@option{--host}が指定されて いて,@option{--build}指定されていないときは,ビルドシステムは @option{--host}と同じだと仮定され,`build_alias'がその値として設 定されます.最終的には,この歴史的に間違っている動作はなくなるでしょう.

    クロスコンパイルを利用可能にするための前者の方法はあまり良くなく,特に, それが安易に使用されると,通常のエンドユーザが不可解なエラーメッセージ を前にして困ってしまいます.コンパイラが汎用的でないときだけのために, @command{configure}はクロスコンパイルモードに入ることが可能です.これ は主に,ユーザからの明示的なフラグを待つ代わりに,@command{configure} をクロスコンパイルの検出を試みるために使用されるためです.

    現在は,@option{--host}が渡されている場合,そしてその状況でだけ, @command{configure}はクロスコンパイルモードに入ります.

    以下は,短いドキュメントです.2.13とその後のものの間で簡単に変換するた め,より複雑な手法が実行されています.以下は将来削除されるので, 以下の内容に依存しないでください

    @option{--host}を指定していて@option{--build}を指定していない場合, @command{configure}が最初のコンパイルテストを実行するときに,コンパイ ラで実行形式が生成されることを実行することで調査してみます.実行が失敗 する場合,クロスコンパイルモードに入ります.これは壊れやすいものです. さらに,コンパイラテストを実行する頃には,ビルドシステムのタイプを修正 するには遅過ぎるかもしれません.そのため,--hostを指定するとき には,確実に--buildも指定してください.

    ./configure --build=i686-pc-linux-gnu --host=m68k-coff
    

    これでクロスコンパイルモードに入ります.コンパイラに @command{configure} の情報を渡すことなくクロスコンパイルする設定から成 り立っている前者のインターフェースは時代遅れです.例えば,以下のような コンフィグレーションを行なっていて,指定されたコンパイラで生成されたコー ドが実行できない場合,@command{configure}は失敗します.

    ./configure CC=m68k-coff-gcc
    

    AC_LIBOBJLIBOBJS

    Autoconf 2.13までは,関数の置換は変数LIBOBJSで開始されていまし た.Autoconf 2.50からは,マクロAC_LIBOBJを代わりに使用すべきで す(see section 一般の関数の調査).Autoconf 2.53からは,LIBOBJSの使 用はエラーになります.

    この変更は,@acronym{GNU}ビルドシステムの構成要素から要求されました. 特に,`configure.ac'のパースで使用される様々な壊れやすいテクニッ クは,すべてトレースを使用することで置換されます.結果として,すべての 動作をトレース可能にする必要があり,それでクリティカルな変数の代入は時 代遅れになります.幸運にもLIBOBJSだけが問題となっていて,それは 美しく処理することが可能です("何も変更する必要はない"ということです).

    典型的なLIBOBJSの使用方法は二つありました.関数の置換を依頼する ことと,Automakeそして/またはLibtoolに対するLIBOBJSを調整するこ とです.

    関数の置換に対しては,修正はすぐにできます.AC_LIBOBJを使用して ください.例えば,以下を考えます.

    LIBOBJS="$LIBOBJS fnmatch.o"
    LIBOBJS="$LIBOBJS malloc.$ac_objext"
    

    以下で置換すべきです.

    AC_LIBOBJ([fnmatch])
    AC_LIBOBJ([malloc])
    

    自動的なde-ANSI-ficationが依頼されたとき,Automakeは,`$U'をベー スファイル名に追加するためにLIBOBJSされたファイル名が必要です. Libtoolは,接尾子が`.lo'になっているLTLIBOBJSの定義が必要 です.人々は,以下のような断片を実行していました.

    # This is necessary so that .o files in LIBOBJS are also built via
    # the ANSI2KNR-filtering rules.
    LIBOBJS=`echo "$LIBOBJS" | sed 's/\.o /\$U.o /g;s/\.o$/\$U.o/'`
    LTLIBOBJS=`echo "$LIBOBJS" | sed 's/\.o/\.lo/g'`
    AC_SUBST(LTLIBOBJS)
    

    `.o'が拡張子ではない可能性があるので,このコードが間違ってい ることに注意してください(6)! 以下のように読み換えてください.

    # This is necessary so that .o files in LIBOBJS are also built via
    # the ANSI2KNR-filtering rules.
    LIB@&t@OBJS=`echo "$LIB@&t@OBJS" |
                 sed 's,\.[[^.]]* ,$U&,g;s,\.[[^.]]*$,$U&,'`
    LTLIBOBJS=`echo "$LIB@&t@OBJS" |
               sed 's,\.[[^.]]* ,.lo ,g;s,\.[[^.]]*$,.lo,'`
    AC_SUBST(LTLIBOBJS)
    

    もやはこれを使用する必要がありません.AC_OUTPUTLIBOBJSLTLIBOBJSを正規化します(そのため,あらゆるバージョンの AutomakeとLibtoolで動作します).この行を削除してください(これはマクロ ではないので,@command{autoupdate}でこの作業を行なうことは不可能です).

    U`Makefile'で使用する必要はありません.

    AC_FOO_IFELSEAC_TRY_FOO

    Autoconf 2.50以来,内部コードでは,一方ではAC_PREPROC_IFELSEAC_COMPILE_IFELSEAC_LINK_IFELSE,そして AC_RUN_IFELSEを使用し,もう一方では反対されている AC_TRY_CPPAC_TRY_COMPILEAC_TRY_LINK,そして AC_TRY_RUNの代わりにAC_LANG_SOURCESAC_LANG_PROGRAMを使用しています.その動機は以下にあります.

    構文の変更だけでなく,哲学的な変更もなされました.正確さの代償として速 度を用いたことを強調しておきますが,今日のAutoconfは,テスティングフレー ムワークの正確さを進展させていて,う〜ん...速度の代償になっていま す.

    なされてはいない完全な例として,ヘッダファイルが,型,構造体, 構造体のメンバー,または関数といった特定の宣言を含んでいるかどうかを調 べる方法が以下にあります.ヘッダファイルで直接grepを実行する代 わりに,AC_EGREP_HEADERを使用してください.調査している `#include' 以外のヘッダファイルでシンボルを定義しているシステムも あるでしょう.

    (悪い)例として,シンボルが,ヘッダファイルで定義されているか,またはC プリプロセッサで定義されているかを,Cプリプロセッサを調査すべきではな い理由がは以下にあります.

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

    上記の例では,適切に書かれている(i)AC_LANG_PROGRAMを使用し, (ii)コンパイラを実行すべきです.

    AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
    [[#if !defined _AIX
    # error _AIX not defined
    #endif
    ]])],
                       [is_aix=yes],
                       [is_aix=no])
    


    Go to the first, previous, next, last section, table of contents.