Autoconfは変化し,歳月を経て時代遅れになった構成物もあります.変更のほ とんどはマクロの呼び出しですが,状況によっては,ツール自身やそのコンセ プトさえも,今では時代遅れと考えられるものもあります.
新しいAutoconfを使用する場合は,この章を完全に飛ばしてもかまいません. ここでの目的は主に,より新しい構成物に変更する方法を理解することで,パッ ケージを更新している管理者を助けることです.
`config.status'は現在,実際に作成されるファイルを指定するための引 数をサポートしています.詳細は,section コンフィグレーションの再生成を参照し てください.以前は環境変数の使用が必要でした.
AC_OUTPUT
とAC_CONFIG_COMMANDS
に与える引数です.
AC_OUTPUT
とAC_CONFIG_COMMANDS
に与
える引数です.
#define
文の置換を行なうファイルです.デフォルトは
AC_CONFIG_HEADERS
に与える引数です.そのマクロが呼び出されていな
い場合,`config.status'はこの値を無視します.
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
等に対しても同様です.)
`config.h.in'を生成するため,@command{autoheader}はそれぞれのシン
ボルに対するテンプレートを構築したり探したりする必要がありました.現在
のAutoconfのリリースでは,AH_VERBATIM
とAH_TEMPLATE
を使用
しますが(see section autoheaderのマクロ),古いリリースでは,ファイル
`acconfig.h'に必要なテンプレートのリストを含めていました.
@command{autoheader}は,コメントと#define
と#undef
の文を,
`acconfig.h' がカレントディレクトリに存在する場合はそこからコピー
します.追加のシンボルをAC_DEFINE
する場合,このファイルを使用す
る必要がありました.
`config.h.in'に情報を前置/後置したい場合,現在のAutoconfのリリー
スでも,AH_TOP
とAH_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'等に依存すべきではありません.
@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}は以下のオプションを受け入れます.
様々な理由で(通常適切に引用婦で囲むことに失敗していて以前の配布物が拡 張できないなどの理由です),いくつかのマクロが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
の使用は時代遅れで推奨できません.現在のマクロ
の記述は,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
が実装されてい
て,単純な発見的手法で選択されます.
有効な組み込みの型を使用する,または,同じ現在のコード(上記参照)を使用
する,もしくはそれより良いものとして,AC_CHECK_TYPES
とともに使
用することをお勧めします.
#if !HAVE_LOFF_T typedef loff_t off_t; #endif
AC_TRY_COMPILE
の時代遅れのバージョンで,それ自身も
AC_COMPILE_IFELSE
で置換され(see section コンパイラの実行),それ
はecho-textが空ではない場合,`checking for echo-text'
を標準出力の最初に追加出力します.メッセージを出力するためには,代わり
にAC_MSG_CHECKING
とAC_MSG_RESULT
を使用してください
(see section メッセージの出力).
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_PROG_LEX
に統合されています.
AC_FUNC_CLOSEDIR_VOID
とAC_HEADER_DIRENT
の呼び出しに似て
いますが,ヘッダファイルが見つかったことを示すため,異なるCプリプロセッ
サマクロの組を定義します.
DIRENT
HAVE_DIRENT_H
SYSNDIR
HAVE_SYS_NDIR_H
SYSDIR
HAVE_SYS_DIR_H
NDIR
HAVE_NDIR_H
LIBS
に@option{-lseq} を追加します.こ
のマクロは以下のように定義されるように使用されていました.
AC_CHECK_LIB(seq, getmntent, LIBS="-lseq $LIBS")現在では,
AC_FUNC_GETMNTENT
で行ないます.
EXEEXT
を定義し,それは現在では自
動的に行なわれます.通常,Unixでは空の文字列で,Win32やOS/2では
`.exe' に設定します.
wait3
が見つかり,第三引数(`struct rusage *')の内容が満たさ
れている場合,HP-UXは違いますが,HAVE_WAIT3
を定義します.
現在では,wait3
はOpen Groupの標準から削除されていて,次のリビジョ
ンの@acronym{POSIX}では無くなるので,移植性の高いプログラムでは
wait3
ではなくwaitpid
を使用すべきです.
main
にしたAC_CHECK_LIB
の呼び出しと同じです.さらに,libraryは,`foo',
@option{-lfoo},または`libfoo.a'のいずれで書くことも可能です.こ
れら全ての状況で,コンパイラに@option{-lfoo}が渡されます.しかし,
libraryをシェル変数することは不可能です.リテラル名にする必要が
あります.
AC_INIT
は単一の引数のみで使用され,それは以下と同じです.
AC_INIT AC_CONFIG_SRCDIR(unique-file-in-source-dir)
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)
AC_LANG_SAVE
で設定されるように,スタックのトップに保存される
languageを選択し,スタックから削除し,
AC_LANG(language)
を呼び出します.
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)
long int
が64ビット幅の場合,LONG_64_BITS
を定義しま
す.その代わりに,一般的なマクロ`AC_CHECK_SIZEOF([long int])'を使
用してください.
mem
関数が`memory.h'で定義されている場合に
NEED_MEMORY_H
を定義するために使用されます.現在は,
`AC_CHECK_HEADERS(memory.h)'と同じです.コードを
NEED_MEMORY_H
ではなくHAVE_MEMORY_H
に依存するように調整し
てください.See section 標準的なシンボル.
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_OUTPUT
の使用は反対されます.これは以下と同じもの
の時代遅れのインターフェースです.
AC_CONFIG_FILES(file...) AC_CONFIG_COMMANDS([default], extra-cmds, init-cmds) AC_OUTPUT
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: []"]])
LIBS
に@option{-lintl}を加えます.このマ
クロは以下を使用していました.
AC_CHECK_LIB(intl, strftime, LIBS="-lintl $LIBS")現在は,代わりに
AC_FUNC_STRFTIME
を呼び出します.
HAVE_RESTARTABLE_SYSCALLS
を定義します.このマクロは,システ
ムが一般的に再スタートするかどうかを調査しません -- それは,
(sigaction
ではなく)signal
でインストールされているシグナ
ルハンドラが再スタートするためのシステムコールを呼び出すかどうかをテス
トします.ハンドラの無いシグナルで中断されたときにシステムコールが再ス
タートされる場合,テストしません.
今日の移植性の高いプログラムでは,システムコールを再スタートしたい場合,
SA_RESTART
を用いてsigaction
を使用すべきです.現在では,
システムコールが再スタート可能かどうかは,コンフィグレーション時の問題
ではなく動的な問題なので,HAVE_RESTARTABLE_SYSCALLS
に依存すべき
ではありません.
#include
文です(現在選択されている言語がFortran 77
の場合,includesは無視されます).このマクロは,CやC++のいずれか
が現在選択されている言語になっている場合,CFLAGS
や
CXXFLAGS
を使用し,コンパイル時には同様にCPPFLAGS
を使用し
ます.Fortran 77が現在選択されている言語の場合,FFLAGS
がコンパ
イルで使用されるでしょう.
#include
文です(現在選択されている言語がFortran 77
の場合,includesは無視されます).このマクロは,CやC++のいずれか
が現在選択されている言語になっている場合,CFLAGS
や
CXXFLAGS
を使用し,コンパイル時には同様にCPPFLAGS
を使用し
ます.Fortran 77が現在選択されている言語の場合,FFLAGS
がコンパ
イルで使用されるでしょう.しかし,LDFLAGS
とLIBS
は,あら
ゆる状況でリンク時に使用されます.
USG
を定義します.これからはUSG
ではなく
HAVE_STRING_H
に依存するようにすべきです.See section 標準的なシンボル.
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=])
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.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
によって)echo
やAC_VERBOSE
を使用していた場合,
@command{configure}スクリプトの出力は,AC_MSG_CHECKING
と
AC_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_DEFUN
はAC_PROVIDE
を
自動的に呼び出し, AC_REQUIRE
のために呼び出されるマクロが,画面
上で入れ子状になっている`checking...'メッセージを妨げないよう
に,他のマクロを中断していないことを確かめます.古い方法を使用し続けて
も実際に害はありませんが,便利さと美しさが現象します.See section マクロの定義.
恐らく,Autoconfと共にやってくるマクロを,何かをする方法のガイドとして 見ることになるでしょう.新しいバージョンのものを見ることは,スタイルが 改善されているものもあり,新しい機能も利用しているので,よい考えでしょ う.
文書化されていないAutoconfの内部(マクロ,変数,変換)を使用して,トリッ キーなことをしていた場合,なされた変更を考慮するため,変更する必要があ るかどうか調査してください.恐らくkludeする代わりに,バージョン2で公式 にサポートされたテクニックを使用することができます.そうしなければダメ でしょう.
ローカルで書かれた特徴のテストを高速化するため,キャッシュを加えてくだ さい.共有可能なマクロをカプセル化するため,テストが一般的に十分役に立 つことを確かめてください.
前のセクション(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とそれ以前では,変数build
,host
,そして
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_LIBOBJ
対LIBOBJS
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_OUTPUT
はLIBOBJS
とLTLIBOBJS
を正規化します(そのため,あらゆるバージョンの
AutomakeとLibtoolで動作します).この行を削除してください(これはマクロ
ではないので,@command{autoupdate}でこの作業を行なうことは不可能です).
U
を`Makefile'で使用する必要はありません.
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])
Go to the first, previous, next, last section, table of contents.