[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Autoconfは変化し,歳月を経て時代遅れになった構成物もあります.変更のほと んどはマクロの呼び出しですが,状況によっては,ツール自身やそのコンセプト さえも,今では時代遅れと考えられるものもあります.
新しいAutoconfを使用する場合は,この章を完全に飛ばしてもかまいません.こ こでの目的は主に,より新しい構成物に変更する方法を理解することで,パッケー ジを更新している管理者を助けることです.
15.1 時代遅れの`config.status'の呼び出し | Different calling convention | |
15.2 `acconfig.h' | Additional entries in `config.h.in' | |
15.3 `configure.ac'を現代風にするためにautoupdate を使用する | Automatic update of `configure.ac' | |
15.4 時代遅れのマクロ | Backward compatibility macros | |
15.5 バージョン1からの更新 | Tips for upgrading your files | |
15.6 バージョン2.13からの更新 | Some fresher tips |
`config.status'は現在,実際に作成されるファイルを指定するための引数 をサポートしています.詳細は,コンフィグレーションの再生成を参照してく ださい.以前は環境変数の使用が必要でした.
実行するコマンドのタグです.デフォルトは,`configure.ac'内の
AC_OUTPUT
とAC_CONFIG_COMMANDS
に与える引数です.
`@variable@'の置換を実行するファイルです.デフォルトは,
`configure.ac'内のAC_OUTPUT
とAC_CONFIG_COMMANDS
に与え
る引数です.
Cの#define
文の置換を行なうファイルです.デフォルトは
AC_CONFIG_HEADERS
に与える引数です.そのマクロが呼び出されていない
場合,`config.status'はこの値を無視します.
作成されるシンボリックリンクです.デフォルトは,AC_CONFIG_LINKS
に与える引数です.そのマクロが呼び出されていない場合,
`config.status'はこの値を無視します.
コンフィグレーションの再生成で古いインターフェースを使用する例は,以下 のようになります.
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'を生成するため,autoheader
はそれぞれのシンボ
ルに対するテンプレートを構築したり探したりする必要がありました.現在の
Autoconfのリリースでは,AH_VERBATIM
とAH_TEMPLATE
を使用しま
すが(see section 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'等に依存すべきではありません.
autoupdate
を使用する autoupdate
プログラムは,Autoconfマクロを古い名前で呼び出してい
る`configure.ac'ファイルを,現在のマクロ名に更新します.バージョン2
のAutoconfでは,ほとんどのマクロが,より一様で記述的な命名法で名前が変更
されています.新しい方法の記述はSee section マクロ名. 古い名前も動作します
が(古いマクロとそれに対応する新しいマクロのリストはsee section 時代遅れのマクロ),新しいマクロ名を使用するために更新した場合,
`configure.ac'はより可読性の高いものになり,現在のAutoconfマクロを
使用することがより簡単になります.
引数が与えられていない場合,autoupdate
は`configure.ac' を
更新し,元のバージョンを接尾子`~'でバックアップします(または,環境
変数SIMPLE_BACKUP_SUFFIX
が設定されている場合はその値になります).
autoupdate
に引数を与えた場合,`configure.ac'の代わりにそ
のファイルを読み込み,更新されたファイルを標準出力に出力します.
autoupdate
は以下のオプションを受け入れます.
コマンドラインオプションの概要を出力して終了します.
Autoconfのバージョンナンバーを出力して終了します.
処理している段階を報告します.
一時的なファイルを削除しません.
ファイルが変更されていない場合でも強制的に更新します.キャッシュは無視さ れます.
入力ファイルをdirでも探します.複数回の呼び出しは累積されます.ディ レクトリは最後のものから最初のものという順序で見ていきます.
様々な理由で(通常適切に引用婦で囲むことに失敗していて以前の配布物が拡張 できないなどの理由です),いくつかのマクロがAutoconfで時代遅れになってい ます.それらはサポートされていますが,使用を止めるようお願いします.それ らの使用は避けた方が良いでしょう.
Autoconfのバージョン1からバージョン2へ移行している間,より一般的でより記 述的な命名法を使用するために,ほとんどのマクロの名前が変更されましたが, そのシグニチャは変更されていません.以下で,これらのマクロの古い名前と新 しい名前の対応付けがあるものは,署名と記述に対する新しいマクロの定義へ参 照するよう読者を招待します.
AC_FUNC_ALLOCA
有用性の制限のため削除.
このマクロは時代遅れです.何もしません.
システムタイプを決定し,出力変数を標準的なシステムタイプ名に設定します. このマクロが設定する変数の詳細はSee section 標準的なシステムタイプの取得.
ユーザは必要なものに依存して,AC_CANONICAL_BUILD
または
AC_CANONICAL_HOST
のいずれか,またはAC_CANONICAL_TARGET
を使
用することを推奨します.AC_CANONICAL_TARGET
を実行することで,必ず
それ以外の二つのマクロが実行されます.
AC_C_CHAR_UNSIGNED
2.13までのAutoconfでは,このバージョンのAC_CHECK_TYPE
を提供するた
めに使用されていましたが,問題があり反対されていました.第一に,それは
CHECK
一族のメンバーですが,単一のファミリーに過ぎず,調査以上のこ
とを行なっていました.次に,足りない型はtypedef
されず,それらは
#define
されるので,ポインタ型の場合は互換性がなくなってしまうはず
です.
このAC_CHECK_TYPE
の使用は時代遅れで推奨できません.現在のマクロの
記述は,一般的な型の調査を参照してください.
型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
が実装されていて,
単純な発見的手法で選択されます.
引数が三つまたは四つある場合,現在のバージョンが使用されます.
二番目の引数にCやC++の型がある場合,時代遅れのバージョンが使用されます. 引数がCやC++に組み込まれている型,または`_t'で終るC識別子で, さらに一つの`[(* 'が続き,その後にゼロ以上の`[]()* _a-zA-Z0-9' 以外の文字列が続く場合はこうなります.
二番目の引数が有効なCとC++のアルファベットで綴られている型の場合,ユーザ は警告され,現在のバージョンが使用されます.
それ以外では,現在のバージョンが使用されます.
有効な組み込みの型を使用する,または,同じ現在のコード(上記参照)を使用す
る,もしくはそれより良いものとして,AC_CHECK_TYPES
とともに使用す
ることをお勧めします.
#if !HAVE_LOFF_T typedef loff_t off_t; #endif |
`AC_MSG_NOTICE([checking feature-description…]'と同じで す.
これは,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環境を調査し,その状況ではシェル変数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 <signal.h> /* NetBSD declares sys_siglist in unistd.h. */ #if HAVE_UNISTD_H # include <unistd.h> #endif ]) |
何もせず,現在はAC_PROG_LEX
に統合されています.
AC_FUNC_CLOSEDIR_VOID
とAC_HEADER_DIRENT
の呼び出しに似てい
ますが,ヘッダファイルが見つかったことを示すため,異なるCプリプロセッサ
マクロの組を定義します.
ヘッダ | 古いシンボル | 新しいシンボル |
`dirent.h' | | |
`sys/ndir.h' | | |
`sys/dir.h' | | |
`ndir.h' | | |
DYNIX/ptxの場合,出力変数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
このマクロは,function引数を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
Cの型int
が16ビット幅の場合,INT_16_BITS
を定義します.代わ
りに`AC_CHECK_SIZEOF(int)'を使用してください.
AIX (Silicon Graphics UNIX)の場合,出力変数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(C)'と同じです.
`AC_LANG(C++)'と同じです.
`AC_LANG(Fortran 77)'と同じです.
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
Cの型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 section 標準的なシンボル.
AC_CYGWIN
に似ていますが,それはMingW32コンパイラの環境を調査し
MINGW32
を設定します.
AC_PROG_CC_C_O
AC_FUNC_MMAP
AC_TYPE_MODE_T
`.c'ファイルが除外された後,コンパイラの出力に基づいて,出力変数
OBJEXT
を定義します.通常,Unixでは`o'で,Win32では
`obj'に設定します.現在はコンパイラの調査マクロがこれを自動的に処理
します.
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
を使用
することを推奨します.
AC_TYPE_OFF_T
引数を用いたAC_OUTPUT
の使用は反対されます.これは以下と同じものの
時代遅れのインターフェースです.
AC_CONFIG_FILES(file…) AC_CONFIG_COMMANDS([default], extra-cmds, init-cmds) AC_OUTPUT |
`config.status'の終りに実行する追加のシェルコマンドと,
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
有用性の制限のため削除されました.
SCO UNIXの場合,出力変数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
`AC_COMPILE_IFELSE([AC_LANG_SOURCE([[includes]], [[function-body]])], [action-if-true], [action-if-false])'と同じです(see section コンパイラの実行).
このマクロは,includesとfunction-bodyの両方を二重に引用符で 囲みます.
CとC++に対して,includesはfunction-bodyにあるコードが必要と
するすべての#include
文です(現在選択されている言語がFortranや
Fortran 77 の場合,includesは無視されます).コンパイラやコンパイル
フラグは,現在の言語(see section 言語の選択)によって決定されます.
`AC_PREPROC_IFELSE([AC_LANG_SOURCE([[input]])], [action-if-true], [action-if-false])'と同じです (see section プリプロセッサの実行).
このマクロはinputを二重に引用符で囲みます.
`AC_LINK_IFELSE([AC_LANG_SOURCE([[includes]], [[function-body]])], [action-if-true], [action-if-false])'と同じです(see section コンパイラの実行).
このマクロは,includesとfunction-bodyの両方を二重に引用符で 囲みます.
現在の言語に依存して(see section 言語の選択),function-bodyの中身 にある関数をコンパイルしリンクすることが可能かどうかを調べるテストプログ ラムを作成します.ファイルのコンパイルとリンクが成功する場合,シェルコマ ンドaction-if-foundを実行し,それ以外ではaction-if-not-found を実行します.
このマクロは,includesとfunction-bodyの両方を二重に引用符で 囲みます.
CとC++に対して,includesはfunction-bodyにあるコードが必要と
するすべての#include
文です(現在選択されている言語がFortran 77 の
場合,includesは無視されます).コンパイラとコンパイルフラグは現在
の言語(see section 言語の選択)で決定され,リンクではLDFLAGS
と
LIBS
が追加で使用されます.
このマクロは,`AC_LINK_IFELSE([AC_LANG_CALL([[includes]], [[function-body]])], [action-if-true], [action-if-false])'と同じです.
`AC_RUN_IFELSE([AC_LANG_SOURCE([[program]], [action-if-true], [action-if-false], [action-if-cross-compiling])'と同じです(see section 実行時の動作の調査).
AC_TYPE_UID_T
`AC_CHECK_HEADERS(unistd.h)'と同じです.
BSD文字列関数が`strings.h'で定義されている場合,
USG
を定義します.これからはUSG
ではなくHAVE_STRING_H
に依存するようにすべきです.See section 標準的なシンボル.
AC_FUNC_UTIME_NULL
キャッシュファイルが現在のホスト,ターゲット,そしてビルドシステムのタイ プで矛盾がある場合,cmdを実行したりデフォルトのエラーメッセージを 出力したりするために使用されていました.これは現在デフォルトで処理されま す.
AC_MSG_RESULT
.
AC_FUNC_VFORK
AC_FUNC_VPRINTF
AC_FUNC_WAIT3
AC_MSG_WARN
AC_C_BIGENDIAN
このマクロは,Xenixの場合に出力変数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
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 |
Autoconfでインストールされた`aclocal.m4'がある場合,(特定のパッケー
ジのソースディレクトリと対立するので),それを`acsite.m4'に名前を変
更する必要があります.See section configure
を作成するため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@'を,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@ |
周りに`@'が無い変数の置換をする古い動作は削除されました.
Autoconfバージョン2でマクロの多くは名前が変更されました.まだ古い名前を
使用することも可能ですが,新しいものはより明確で,それらのドキュメントは
簡単に見つかります.古いマクロに対する新しい名前の表は,See section 時代遅れのマクロ. 新しいマクロを使用するように`configure.ac'を変換するため,
autoupdate
プログラムを使用してください.See section `configure.ac'を現代風にするためにautoupdate
を使用する.
マクロには,より良い仕事をする似たものに置き換えられたものもありますが,
呼び出しに互換性がありません.autoconf
実行中に,時代遅れのマク
ロの呼び出しに関する警告がある場合,無視しても大丈夫ですが,時代遅れのマ
クロの置換に関して出力されるアドバイスに従う場合,configure
ス
クリプトはより良い仕事をします.特に,テストの結果を報告するメカニズムが
変化しました.(おそらくAC_COMPILE_CHECK
によって)echo
や
AC_VERBOSE
を使用していた場合,configure
スクリプトの出力
は,AC_MSG_CHECKING
とAC_MSG_RESULT
に変えた方が良く見えるで
しょう.See section メッセージの出力. これらのマクロは,キャッシュ変数に関連
して最高の仕事をします.See section 結果のキャッシュ.
シェル変数のDEFS
を調査することで,前のテストの結果を調査していた
場合,それらのテストに対するキャッシュ変数の値を調査することに切り替える
必要があります.DEFS
は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からの更新)の導入は,このセクションにも全く適して いるなあ....
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 対LIBOBJS | LIBOBJS is a forbidden token | |
15.6.5 AC_FOO_IFELSE 対AC_TRY_FOO | A more generic scheme for testing sources |
紹介すべき最も重要な変更です.ほとんどのマクロの実装は完全に変更されまし た.コードの分解,エラーメッセージの改善,ユーザインターフェースの一貫性 などが,このことで可能になりました.残念ながら副作用として,これまで(奇 跡的に)動作していた構成物には,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_
の名前空間で統合されて
います.しかし,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 $ |
コンパイラ作者の経験とそれ以降の長期にわたる公開討論を基にして,一連のク ロスコンパイルの多くの面が変更されました.
ビルド,ホスト,そしてターゲットアーキテクチャタイプの違いに関連すること.
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 |
AC_LIBOBJ
対LIBOBJS
Autoconf 2.13までは,関数の置換は変数LIBOBJS
で開始されていました.
Autoconf 2.50からは,マクロAC_LIBOBJ
を代わりに使用すべきです
(see section 一般の関数の調査).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'で使用する必要はありません.
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
などは,その引数を
二重の引用符で囲みます.
一方ではソースを生成し,もう一方ではプログラムを実行するように,組合せが 増加しても分解することで解決します.
この手法はプレーンのCとC++より多くの言語をサポートする助けとなります.
構文の変更だけでなく,哲学的な変更もなされました.正確さの代償として速度 を用いたことを強調しておきますが,今日の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]) |
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Akihiro Sagawa on June, 15 2005 using texi2html 1.70.