| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
Autoconfは変化し，歳月を経て時代遅れになった構成物もあります．変更のほと んどはマクロの呼び出しですが，状況によっては，ツール自身やそのコンセプト さえも，今では時代遅れと考えられるものもあります．
新しいAutoconfを使用する場合は，この章を完全に飛ばしてもかまいません．こ こでの目的は主に，より新しい構成物に変更する方法を理解することで，パッケー ジを更新している管理者を助けることです．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
`config.status'は現在，実際に作成されるファイルを指定するための引数 をサポートしています．詳細は，14. コンフィグレーションの再生成を参照してく ださい．以前は環境変数の使用が必要でした．
AC_OUTPUTとAC_CONFIG_COMMANDSに与える引数です．AC_OUTPUTとAC_CONFIG_COMMANDSに与え る引数です．#define文の置換を行なうファイルです．デフォルトは AC_CONFIG_HEADERSに与える引数です．そのマクロが呼び出されていない 場合，`config.status'はこの値を無視します．AC_CONFIG_LINKS に与える引数です．そのマクロが呼び出されていない場合， `config.status'はこの値を無視します．14. コンフィグレーションの再生成で古いインターフェースを使用する例は，以下 のようになります．
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等に対しても同様です．)
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
`config.h.in'を生成するため，autoheaderはそれぞれのシンボ ルに対するテンプレートを構築したり探したりする必要がありました．現在の Autoconfのリリースでは，AH_VERBATIMとAH_TEMPLATEを使用しま すが(see 節 4.8.3 autoheaderのマクロ)，古いリリースでは，ファイル `acconfig.h'に必要なテンプレートのリストを含めていました． autoheaderは，コメントと#defineと#undefの文を， `acconfig.h' がカレントディレクトリに存在する場合はそこからコピーし ます．追加のシンボルをAC_DEFINEする場合，このファイルを使用する必 要がありました．
`config.h.in'に情報を前置/後置したい場合，現在のAutoconfのリリース でも，AH_TOPとAH_BOTTOMを提供しています．昔のバージョンの Autoconfにはよく似た機能がありました．`./acconfig.h'に文字列 `@TOP@'が含まれている場合，autoheaderは`@TOP@' が含まれている行の前の行を生成するファイルの先頭にコピーします．同様に， `./acconfig.h'に文字列`@BOTTOM@'が含まれている場合， autoheaderはその行の後の行を生成するファイルの末尾にコピーしま す．これらの文字列のいずれかまたは両方とも省略できます．古いバージョンの Autoconfで同じ効果を生成するための，さらに古い代替方法は，カレントディレ クトリにファイル`file.top'(通常は`config.h.top') や `file.bot'を作成することです．それらが存在する場合， 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'等に依存すべきではありません．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
autoupdateを使用するautoupdateを使用する"へのコメント(無し)
autoupdateプログラムは，Autoconfマクロを古い名前で呼び出してい る`configure.ac'ファイルを，現在のマクロ名に更新します．バージョン2 のAutoconfでは，ほとんどのマクロが，より一様で記述的な命名法で名前が変更 されています．新しい方法の記述はSee 節 9.2 マクロ名. 古い名前も動作します が(古いマクロとそれに対応する新しいマクロのリストはsee 節 15.4 時代遅れのマクロ)，新しいマクロ名を使用するために更新した場合， `configure.ac'はより可読性の高いものになり，現在のAutoconfマクロを 使用することがより簡単になります．
引数が与えられていない場合，autoupdateは`configure.ac' を 更新し，元のバージョンを接尾子`~'でバックアップします(または，環境 変数SIMPLE_BACKUP_SUFFIXが設定されている場合はその値になります)． autoupdateに引数を与えた場合，`configure.ac'の代わりにそ のファイルを読み込み，更新されたファイルを標準出力に出力します．
autoupdateは以下のオプションを受け入れます．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
様々な理由で(通常適切に引用婦で囲むことに失敗していて以前の配布物が拡張 できないなどの理由です)，いくつかのマクロがAutoconfで時代遅れになってい ます．それらはサポートされていますが，使用を止めるようお願いします．それ らの使用は避けた方が良いでしょう．
Autoconfのバージョン1からバージョン2へ移行している間，より一般的でより記 述的な命名法を使用するために，ほとんどのマクロの名前が変更されましたが， そのシグニチャは変更されていません．以下で，これらのマクロの古い名前と新 しい名前の対応付けがあるものは，署名と記述に対する新しいマクロの定義へ参 照するよう読者を招待します．
AC_FUNC_ALLOCA
ユーザは必要なものに依存して，AC_CANONICAL_BUILDまたは AC_CANONICAL_HOSTのいずれか，またはAC_CANONICAL_TARGETを使 用することを推奨します．AC_CANONICAL_TARGETを実行することで，必ず それ以外の二つのマクロが実行されます．
AC_C_CHAR_UNSIGNED
AC_CHECK_TYPEを提供するた めに使用されていましたが，問題があり反対されていました．第一に，それは CHECK一族のメンバーですが，単一のファミリーに過ぎず，調査以上のこ とを行なっていました．次に，足りない型はtypedefされず，それらは #defineされるので，ポインタ型の場合は互換性がなくなってしまうはず です．
このAC_CHECK_TYPEの使用は時代遅れで推奨できません．現在のマクロの 記述は，5.9.2 一般的な型の調査を参照してください．
型typeが定義されていない場合，それはC(またはC++)の組み込みの型 defaultに定義されます．例えば，`short'や`unsigned'です．
このマクロは以下と等価です．
AC_CHECK_TYPE([type],,
[AC_DEFINE_UNQUOTED([type], [default],
[Define to `default' if
|
下位互換性のため，二つのバージョンのAC_CHECK_TYPEが実装されていて， 単純な発見的手法で選択されます．
有効な組み込みの型を使用する，または，同じ現在のコード(上記参照)を使用す る，もしくはそれより良いものとして，AC_CHECK_TYPESとともに使用す ることをお勧めします．
#if !HAVE_LOFF_T typedef loff_t off_t; #endif |
AC_TRY_COMPILEの時代遅れのバージョンで，それ自身も AC_COMPILE_IFELSEで置換され(see 節 6.4 コンパイラの実行)，それは echo-textが空ではない場合，`checking for echo-text' を 標準出力の最初に追加出力します．メッセージを出力するためには，代わりに AC_MSG_CHECKINGとAC_MSG_RESULTを使用してください (see 節 7.4 メッセージの出力)．AC_C_CONST
AC_C_CROSSと同じで，さらにそれも時代遅れになっていて，何もしませ ん:-)．CYGWINを`yes'に設 定します．このマクロを使用せず，権威のあるホストの調査手法 AC_CANONICAL_HOSTが使用されています．実際問題として，このマクロは 以下のように定義されています．
AC_REQUIRE([AC_CANONICAL_HOST])[]dnl
case $host_os in
*cygwin* ) CYGWIN=yes;;
* ) CYGWIN=no;;
esac
|
変数CYGWINには，CygWin32を実行しているときは非常に特殊な意味があ ることに注意し，変更すべきではありません．それはこのマクロを使用しないも う一つの理由です．
AC_CHECK_DECLS([sys_siglist],,, [#include |
AC_PROG_LEXに統合されています．AC_FUNC_CLOSEDIR_VOIDとAC_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 |
LIBSに`-lseq' を追加します．この マクロは以下のように定義されるように使用されていました．
AC_CHECK_LIB(seq, getmntent, LIBS="-lseq $LIBS") |
現在では，AC_FUNC_GETMNTENTで行ないます．
EXEEXTを定義し，それは現在では自動 的に行なわれます．通常，Unixでは空の文字列で，Win32やOS/2では`.exe' に設定します．AC_CYGWINに似ていますが，OS/2のEMX環境変数を調査しEMXOS2 を設定します．AC_MSG_ERROR
AC_PATH_X
AC_PATH_XTRA
AC_CHECK_FUNC
wait3が見つかり，第三引数(`struct rusage *')の内容が満たされ ている場合，HP-UXは違いますが，HAVE_WAIT3を定義します．
現在では，wait3はOpen Groupの標準から削除されていて，次のリビジョ ンのPOSIXでは無くなるので，移植性の高いプログラムでは wait3ではなくwaitpidを使用すべきです．
AC_PROG_GCC_TRADITIONAL
AC_TYPE_GETGROUPS
AC_FUNC_GETLOADAVG
AC_CHECK_FUNCS
AC_CHECK_HEADERS
mainにしたAC_CHECK_LIB の呼び出しと同じです．さらに，libraryは，`foo'， `-lfoo'，または`libfoo.a'のいずれで書くことも可能です．これ ら全ての状況で，コンパイラに`-lfoo'が渡されます．しかし， libraryをシェル変数することは不可能です．リテラル名にする必要があ ります．AC_SYS_INTERPRETER (呼び出し規則が異なります)AC_CHECK_HEADER
AC_EGREP_HEADER
AS_HELP_STRING
AC_INITは単一の引数のみで使用され，それは以下と同じです．
AC_INIT AC_CONFIG_SRCDIR(unique-file-in-source-dir) |
AC_C_INLINE
intが16ビット幅の場合，INT_16_BITSを定義します．代わ りに`AC_CHECK_SIZEOF(int)'を使用してください．LIBS に `-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) |
AC_LANG_SAVEで設定されるように，スタックのトップに保存される languageを選択し，スタックから削除し， AC_LANG(language)を呼び出します．AC_LANGで設定されるように)スタックに記憶します．現在 の言語は変更されません．AC_LANG_PUSHが好まれます．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)
|
AC_PROG_LN_S
long intが64ビット幅の場合，LONG_64_BITSを定義します． その代わりに，一般的なマクロ`AC_CHECK_SIZEOF([long int])'を使用して ください．AC_C_LONG_DOUBLE
AC_SYS_LONG_FILE_NAMES
AC_HEADER_MAJOR
mem関数が`memory.h'で定義されている場合に NEED_MEMORY_Hを定義するために使用されます．現在は， `AC_CHECK_HEADERS(memory.h)'と同じです．コードを NEED_MEMORY_HではなくHAVE_MEMORY_Hに依存するように調整して ください．See 節 5.1.1 標準的なシンボル.AC_CYGWINに似ていますが，それはMingW32コンパイラの環境を調査し MINGW32を設定します．AC_PROG_CC_C_O
AC_FUNC_MMAP
AC_TYPE_MODE_T
OBJEXTを定義します．通常，Unixでは`o'で，Win32では `obj'に設定します．現在はコンパイラの調査マクロがこれを自動的に処理 します．AC_OBSOLETEが呼び出しているマクロ名にす べきです．suggestionが与えられている場合，それは警告メッセージの終 りに出力されます．例えば，this-macro-nameの代わりに使用するものを 提案することが可能になります．
例えば以下のようにします．
AC_OBSOLETE([$0], [; use AC_CHECK_HEADERS(unistd.h) instead])dnl |
ユーザに対するより良いサービスとなるので，代わりにAU_DEFUNを使用 することを推奨します．
AC_TYPE_OFF_T
AC_OUTPUTの使用は反対されます．これは以下と同じものの 時代遅れのインターフェースです．
AC_CONFIG_FILES(file...)
AC_CONFIG_COMMANDS([default],
extra-cmds, init-cmds)
AC_OUTPUT
|
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: []"]]) |
AC_TYPE_PID_T
AC_PREFIX_PROGRAM
AC_PROG_CCに統合されました．AC_CHECK_PROGS
AC_PATH_PROGS
AC_CHECK_PROG
AC_EGREP_CPP
AC_PATH_PROG
AC_SYS_RESTARTABLE_SYSCALLS
AC_TYPE_SIGNAL
LIBSに`-lintl'を加えます．このマク ロは以下を使用していました．
AC_CHECK_LIB(intl, strftime, LIBS="-lintl $LIBS") |
現在は，代わりにAC_FUNC_STRFTIMEを呼び出します．
AC_FUNC_SETVBUF_REVERSED
AC_PROG_MAKE_SET
AC_CHECK_SIZEOF
AC_TYPE_SIZE_T
AC_HEADER_STAT
AC_HEADER_STDC
AC_FUNC_STRCOLL
AC_CHECK_MEMBERS
AC_STRUCT_ST_BLOCKS
AC_CHECK_MEMBERS
HAVE_RESTARTABLE_SYSCALLSを定義します．このマクロは，システムが一 般的に再スタートするかどうかを調査しません -- それは，(sigaction ではなく)signalでインストールされているシグナルハンドラが再スター トするためのシステムコールを呼び出すかどうかをテストします．ハンドラの無 いシグナルで中断されたときにシステムコールが再スタートされる場合，テスト しません．
今日の移植性の高いプログラムでは，システムコールを再スタートしたい場合， SA_RESTARTを用いてsigactionを使用すべきです．現在では，シ ステムコールが再スタート可能かどうかは，コンフィグレーション時の問題では なく動的な問題なので，HAVE_RESTARTABLE_SYSCALLSに依存すべきではあ りません．
AC_DECL_SYS_SIGLIST
AC_TRY_CPPになり，それもAC_PREPROC_IFELSEで置き換えられま した．AC_TRY_RUNになり，それもAC_RUN_IFELSEで置き換えられました．AC_STRUCT_TIMEZONE
AC_HEADER_TIME
このマクロは，includesとfunction-bodyの両方を二重に引用符で 囲みます．
CとC++に対して，includesはfunction-bodyにあるコードが必要と するすべての#include文です(現在選択されている言語がFortranや Fortran 77 の場合，includesは無視されます)．コンパイラやコンパイル フラグは，現在の言語(see 節 6.1 言語の選択)によって決定されます．
このマクロはinputを二重に引用符で囲みます．
このマクロは，includesとfunction-bodyの両方を二重に引用符で 囲みます．
現在の言語に依存して(see 節 6.1 言語の選択)，function-bodyの中身 にある関数をコンパイルしリンクすることが可能かどうかを調べるテストプログ ラムを作成します．ファイルのコンパイルとリンクが成功する場合，シェルコマ ンドaction-if-foundを実行し，それ以外ではaction-if-not-found を実行します．
このマクロは，includesとfunction-bodyの両方を二重に引用符で 囲みます．
CとC++に対して，includesはfunction-bodyにあるコードが必要と するすべての#include文です(現在選択されている言語がFortran 77 の 場合，includesは無視されます)．コンパイラとコンパイルフラグは現在 の言語(see 節 6.1 言語の選択)で決定され，リンクではLDFLAGSと LIBSが追加で使用されます．
AC_TYPE_UID_T
USGを定義します．これからはUSGではなくHAVE_STRING_H に依存するようにすべきです．See 節 5.1.1 標準的なシンボル.AC_FUNC_UTIME_NULL
AC_MSG_RESULT.AC_FUNC_VFORK
AC_FUNC_VPRINTF
AC_FUNC_WAIT3
AC_MSG_WARN
AC_C_BIGENDIAN
LIBSに`-lx'を追加するた めに使用されていました．また，`dirent.h'が調査され，LIBS を `-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=])
|
AC_DECL_YYTEXT
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
Autoconfバージョン2は，バージョン1とほとんど下位互換性があります．しかし， 何かをするときにより良くなる方法も導入していますし，バージョン1の醜いも のにはサポートしなくなったものもあります．そのため，`configure.ac' の洗練具合に依存して，バージョン2に更新するための手作業が必要になります． この章は，更新時に見るべき問題点も示します．また，configureス クリプトは，バージョン2の新しい機能でより良くなります．変更点は， Autoconf配布物のファイル`NEWS'に概要が書かれています．
15.5.1 ファイル名の変更 Files you might rename 15.5.2 Makefileの変更 New things to put in `Makefile.in' 15.5.3 変更されたマクロ Macro calls you might replace 15.5.4 変更された結果 Changes in how to check test results 15.5.5 マクロの書き方の変更 Better ways to write your own macros
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
Autoconfでインストールされた`aclocal.m4'がある場合，(特定のパッケー ジのソースディレクトリと対立するので)，それを`acsite.m4'に名前を変 更する必要があります．See 節 3.4 configureを作成するためautoconfを使用する.
パッケージで`install.sh'を配布する場合，make組み込みルールが， `install'と呼ばれる意図しないファイルを作成するので， `install-sh'に名前を変更してください．AC_PROG_INSTALLは両方 の名前でスクリプトを探しますが，新しい名前を使用するのが最善です．
`config.h.top'，`config.h.bot'，または`acconfig.h'を使用 している場合，そのまま使用することは可能ですが，AH_マクロを使用す るとバラバラになりません．See 節 4.8.3 autoheaderのマクロ.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
`Makefile.in'ファイルに`@CFLAGS@'，`@CPPFLAGS@'，そし て`@LDFLAGS@'を，configure実行時に，環境変数としてこれ らの変数の値を利用できるので，それらを加えてください．必要ではありません が，ユーザにとって便利です．
出力ファイルに，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@ |
周りに`@'が無い変数の置換をする古い動作は削除されました．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
Autoconfバージョン2でマクロの多くは名前が変更されました．まだ古い名前を 使用することも可能ですが，新しいものはより明確で，それらのドキュメントは 簡単に見つかります．古いマクロに対する新しい名前の表は，See 節 15.4 時代遅れのマクロ. 新しいマクロを使用するように`configure.ac'を変換するため， autoupdateプログラムを使用してください．See 節 15.3 `configure.ac'を現代風にするためにautoupdateを使用する.
マクロには，より良い仕事をする似たものに置き換えられたものもありますが， 呼び出しに互換性がありません．autoconf実行中に，時代遅れのマク ロの呼び出しに関する警告がある場合，無視しても大丈夫ですが，時代遅れのマ クロの置換に関して出力されるアドバイスに従う場合，configureス クリプトはより良い仕事をします．特に，テストの結果を報告するメカニズムが 変化しました．(おそらくAC_COMPILE_CHECK によって)echoや AC_VERBOSEを使用していた場合，configureスクリプトの出力 は，AC_MSG_CHECKINGとAC_MSG_RESULTに変えた方が良く見えるで しょう．See 節 7.4 メッセージの出力. これらのマクロは，キャッシュ変数に関連 して最高の仕事をします．See 節 7.3 結果のキャッシュ.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
シェル変数のDEFSを調査することで，前のテストの結果を調査していた 場合，それらのテストに対するキャッシュ変数の値を調査することに切り替える 必要があります．DEFSはconfigure実行中にも存在しません． それは出力ファイルを生成するときのみ作成されます．バージョン1からのこの 違いは，正確にその変数を引用符で囲むことが，あまりに厄介で， AC_DEFINEを毎回呼び出すことは，非効率だと分かったためです． See 節 7.3.1 キャッシュ変数名.
例えば，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 節 7.2 出力変数の設定.
現在，Autoconfマクロが設定した真偽値のシェル変数のすべては，真の値に対し て`yes'が使用され．偽に対してはほとんど`no'を使用しますが，下 位互換性のため，代わりに空の文字列を使用するものもあります．真に対して1 や`t'にシェル変数が設定されることを期待する場合，テストを変更する必 要があります．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
独自のマクロを定義するとき，現在はdefineの代わりにAC_DEFUN を使用すべきです．AC_DEFUNはAC_PROVIDEを自動的に呼び出し， AC_REQUIREのために呼び出されるマクロが，画面上で入れ子状になって いる`checking...'メッセージを妨げないように，他のマクロを中断し ていないことを確かめます．古い方法を使用し続けても実際に害はありませんが， 便利さと美しさが現象します．See 節 9.1 マクロの定義.
恐らく，Autoconfと共にやってくるマクロを，何かをする方法のガイドとして見 ることになるでしょう．新しいバージョンのものを見ることは，スタイルが改善 されているものもあり，新しい機能も利用しているので，よい考えでしょう．
文書化されていないAutoconfの内部(マクロ，変数，変換)を使用して，トリッキー なことをしていた場合，なされた変更を考慮するため，変更する必要があるかど うか調査してください．恐らくkludeする代わりに，バージョン2で公式にサポー トされたテクニックを使用することができます．そうしなければダメでしょう．
ローカルで書かれた特徴のテストを高速化するため，キャッシュを加えてくださ い．共有可能なマクロをカプセル化するため，テストが一般的に十分役に立つこ とを確かめてください．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
前のセクション(see 節 15.5 バージョン1からの更新)の導入は，このセクションにも全く適して いるなあ....
Autoconfバージョン2.50は，バージョン2.13とほとんど下位互換性があります． しかし，何かをするときより良くする方法も導入し，バージョン2.13の醜いもの にはサポートしなくなったものもあります．そのため，`configure.ac'の 洗練具合に依存して，バージョン2.50に更新するための手作業が必要になります． この章は，更新時に見るべき問題点も示します．また，configureス クリプトは，バージョン2.50の新しい機能でより良くなります．変更点は， Autoconf 配布物のファイル`NEWS'に概要が書かれています．
15.6.1 引用符で囲むことの変更 Broken code which used to work 15.6.2 新しいマクロ Interaction with foreign macros 15.6.3 ホストとクロスコンパイル Bugward compatibility kludges 15.6.4 AC_LIBOBJ対LIBOBJSLIBOBJS is a forbidden token 15.6.5 AC_FOO_IFELSE対AC_TRY_FOOA more generic scheme for testing sources
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
紹介すべき最も重要な変更です．ほとんどのマクロの実装は完全に変更されまし た．コードの分解，エラーメッセージの改善，ユーザインターフェースの一貫性 などが，このことで可能になりました．残念ながら副作用として，これまで(奇 跡的に)動作していた構成物には，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 $ |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
Autoconfは何年も休止中だったので，その間AutomakeがAutoconfのようなマクロ を提供していました．現在は，Autoconf 2.50がこれらのマクロのより良いバー ジョンを提供していて，AM_ではなくAC_の名前空間で統合されて います．しかし，autoupdateで容易に更新できるように，そのような AM_マクロも結合されて提供されています．
残念ながら，Automakeはこれらのマクロ名を引用符で囲んでいませんでした．そ のため，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 $ |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
コンパイラ作者の経験とそれ以降の長期にわたる公開討論を基にして，一連のク ロスコンパイルの多くの面が変更されました．
configureでそれらを指定するコマンドラインインターフェース．
configureで定義される変数．
ビルド，ホスト，そしてターゲットアーキテクチャタイプの違いに関連すること は解決しています．一連のデフォルトは，現在は単純です．ターゲットのデフォ ルトはホスト，ホストはビルド，そしてビルドはconfig.guess の結 果となっています．それにもかかわらず，2.13から2.50へ容易に変換するために， 以下の変換手法が実装されています．それは，リリースの組を完全に利用不可能 にすることはできないので，それに依存しないでください (直すより問 題が生じることが多いので，我々はそれを維持することは不可能です)．
`--build'または`--host'で指定しない限り，すべてのデフォル トはconfig.guessの実行結果になります．指定する場合は，デフォル トは指定したシステムタイプになります．両方を指定していて異なっている場合， テストと要求された実行物をの実行しないように，configureはクロ スコンパイルモードになります．
ヒント：config.guessの結果に優先させたい場合は， `--host'ではなく`--build'の方が好ましくなっています．将来 は，`--host'でビルドシステムタイプを優先しなくなるでしょう． --hostを指定する場合も，確実に--buildも指定してください．
下位互換性のため，configureはシステムタイプ自身をオプションと して受け入れます．そのようなオプションは，ビルド，ホスト，そしてターゲッ トのシステムタイプのデフォルトに優先されます．以下のコンフィグレーション 命令では，NetBSD/alphaで実行するのですが，ビルドプラットフォー ムにもなるGNU Hurd/sparcのコードを生成する一連のクロスツールが コンフィグレーションされます．
./configure --host=alpha-netbsd sparc-gnu |
Autoconf 2.13とそれ以前では，変数build，host，そして targetは，AC_CANONICAL_BUILDの呼び出しの前後で異なる意味を 持っていました．現在は，`--build'の引数を指定することで，それは厳 密な意味でbuild_aliasにコピーされ，それ以外では空のままになります． AC_CANONICAL_BUILDの後で，buildは標準的なビルドタイプに設 定されます．変換を容易にするため，以前の内容は，build_aliasと同じ です．この壊れた機能に依存しないように してください．
下位互換性を考慮した手法は上のようになり，`--host'が指定されてい て，`--build'指定されていないときは，ビルドシステムは `--host'と同じだと仮定され，`build_alias'がその値として設定 されます．最終的には，この歴史的に間違っている動作はなくなるでしょう．
クロスコンパイルを利用可能にするための前者の方法はあまり良くなく，特に， それが安易に使用されると，通常のエンドユーザが不可解なエラーメッセージを 前にして困ってしまいます．コンパイラが汎用的でないときだけのために， configureはクロスコンパイルモードに入ることが可能です．これは 主に，ユーザからの明示的なフラグを待つ代わりに，configure をク ロスコンパイルの検出を試みるために使用されるためです．
現在は，`--host'が渡されている場合，そしてその状況でだけ， configureはクロスコンパイルモードに入ります．
以下は，短いドキュメントです．2.13とその後のものの間で簡単に変換するため， より複雑な手法が実行されています．以下は将来削除されるので，以下の 内容に依存しないでください．
`--host'を指定していて`--build'を指定していない場合， configureが最初のコンパイルテストを実行するときに，コンパイラ で実行形式が生成されることを実行することで調査してみます．実行が失敗する 場合，クロスコンパイルモードに入ります．これは壊れやすいものです．さらに， コンパイラテストを実行する頃には，ビルドシステムのタイプを修正するには遅 過ぎるかもしれません．そのため，--hostを指定するときには，確実に --buildも指定してください．
./configure --build=i686-pc-linux-gnu --host=m68k-coff |
これでクロスコンパイルモードに入ります．コンパイラにconfigure の情報を渡すことなくクロスコンパイルする設定から成り立っている前者のイン ターフェースは時代遅れです．例えば，以下のようなコンフィグレーションを行 なっていて，指定されたコンパイラで生成されたコードが実行できない場合， configureは失敗します．
./configure CC=m68k-coff-gcc |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
AC_LIBOBJ対LIBOBJS
AC_LIBOBJ対LIBOBJS"へのコメント(無し)
Autoconf 2.13までは，関数の置換は変数LIBOBJSで開始されていました． Autoconf 2.50からは，マクロAC_LIBOBJを代わりに使用すべきです (see 節 5.5.3 一般の関数の調査)．Autoconf 2.53からは，LIBOBJSの使用は エラーになります．
この変更は，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_OUTPUTはLIBOBJS とLTLIBOBJSを正規化します(そのため，あらゆるバージョンのAutomake とLibtoolで動作します)．この行を削除してください(これはマクロではないの で，autoupdateでこの作業を行なうことは不可能です)．
Uを`Makefile'で使用する必要はありません．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
AC_FOO_IFELSE対AC_TRY_FOO
AC_FOO_IFELSE対AC_TRY_FOO"へのコメント(無し)
Autoconf 2.50以来，内部コードでは，一方ではAC_PREPROC_IFELSE， AC_COMPILE_IFELSE，AC_LINK_IFELSE，そして AC_RUN_IFELSEを使用し，もう一方では反対されている AC_TRY_CPP，AC_TRY_COMPILE，AC_TRY_LINK，そして AC_TRY_RUNの代わりにAC_LANG_SOURCESと AC_LANG_PROGRAMを使用しています．その動機は以下にあります．
AC_TRY_COMPILEなどは，その引数を 二重の引用符で囲みます．
構文の変更だけでなく，哲学的な変更もなされました．正確さの代償として速度 を用いたことを強調しておきますが，今日の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])
|
| [ << ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |