前: Local Macros, 上: configure
aclocalの消滅が予想されています.この機能はAutomakeで提供す るものではありません.AutomakeはMakefileの生成に焦点を絞るべき です.M4マクロの処理は,本当はAutoconfの仕事でしょう. aclocalを使用するためだけにAutomakeをインストールしていて, それ以外でのautomakeを使用しない人もいますが,それこそが,こ の機能が場違いであることを示しています.
新たな実装は,若干違うものになる可能性があります.例えば,Local Macrosで議論したm4/形式の配置を強制し, /usr/share/aclocal/から持ってきたサードパーティーのマクロをこの ディレクトリにコピー(そして更新)するようになるかもしれません.
我々には,これがどうすれば良いか分かりません.このことは,これまでに何 度も議論されてきましたが,誰かがそのような不明確な作業を自分に科さなけ ればなりません.
ユーザの視点からは,aclocalの消滅は痛ましいものになり得ます. がたがたしないように切替えるための予防策があります.それは自分で aclocalを呼び出さないことです.こいつをautoreconf の制御下に追いやったり,Automakeのリビルドのルールにしたりしてください. 希望としては,aclocalが無くなったとき,すべての面倒が見られ ていて,崩壊後に悩む必要が無いようにしたいことでしょう.それ以外で,直 接,またはスクリプトからaclocalを呼び出している場合,変更に 注意して下さい.
aclocal,libtoolize,gettextizeまたは autopoint,autoconf,autoheader,そして automakeを正しい順序で呼び出している,bootstrap.shや autogen.shといったスクリプトが一緒になっているパッケージもたく さんあります.実際,これはautoreconfでできることと全く同じで す.bootstrap.shやautogen.shのようなスクリプトがパッケー ジにある場合,autoreconfの使用を検討してみて下さい.それは論 理的にずいぶん簡単になり(管理には旨味はないけどね!),スクリプトはもは や不要で,aclocalを直接呼び出す場所も無くなります.
しばらくは,サードパーティのパッケージはパブリックマクロを
/usr/share/aclocal/
にインストールし続けるでしょう.
aclocalが別のツールに置き換えられる場合,ディレクトリ名を変
更することに意味がありますが,すべてのマクロの後方互換性をより容易に提
供するため,/usr/share/aclocal/
をサポートし続けるように書かれる
ことになるでしょう(see Extending aclocal).