26.3 なぜAutomakeはワイルドカードをサポートしないのですか？

開発者は怠けものです．ファイルの追加，削除，または名前の変更のたびに， Makefile.amの更新を忘れないようにする必要がないよう， Makefile.amでワイルドカードを使用したいときもよくあります．

これにはいくつかの欠点があります．

• CVS(やそれに似たもの)を使用している管理者は，cvs addやcvs rmを実行する必要があることを，とにかく覚えておく必要があります．とい うわけで，Makefile.amも反射的にすぐ行なうようになります．

  逆に，アプリケーションが完全ではない場合，Makefile.amにファイル を追加する必要があるので，それをcvs addすることを覚えておく手助 けになります．

• ワイルドカードを使用することで，間違ってファイルを配布しやすくなります． 例えば，開発者が(いわゆるテストケースで)調査するためのコードで，それは 配布物の一部にすべきではありません．
• ワイルドカードを使用すると，間違ってファイルを削除しやすくなります．例 えば，ある開発者が新しいファイルを作成し，それをたくさんの場所で使用し ているが，これをコミットするのを忘れているとします．他の開発者は，不完 全なプロジェクトをチェックアウトしても，ファイルが足りなくても，問題無 く`make dist'を実行することが可能です．
• ファイルをリストアップすると，配布するものを正確に制御できます． 配布されるべきファイルがツリーに無い場合，make distで文句を言わ れます．さらに，リストアップしている以上のファイルを配布することもあり ません．
• おしまいに，ファイルをMakefile.amに追加し忘れることは滅多に無く， それは，追加していない場合，コンパイルもインストールもされず，テストす らできないでしょう．

それらすべてを却下するほとワイルドカードに十分な価値があるという反対意 見があるかもしれませんが，まだ哲学的な欠点もあります．Automakeにワイル ドカードを伝えるためのパッチを書き始める前に，主な技術的な問題を見てい きましょう．それは移植性です．

$(wildcard ...)はGNU makeで動作しますが，他の makeの実装では移植性がありません．

Automakeで$(wildcard ...)をサポートする唯一の方法は， automakeの実行時に$(wildcard ...)を展開することで す．結果として得られるMakefile.inには，$(wildcard ...)が 使用されておらず，すべてのファイルをリストアップしているので移植性があ ります．しかしそれは，ファイルを追加，削除，または名前の変更をするたび に，開発者がautomakeを実行する必要があるということを意味します．

Makefile.amを編集するより，実際は若干勝っています．確かに， emacs Makefile.am; makeと入力するよりautomake; makeと入 力する方が簡単で速いでしょう．しかし，この構文のサポートを追加するのに 十分なパッチを書くことを邪魔する人はいません．Makefile.amや個別 のMakefileの断片にファイルリストを生成するスクリプトを使う人も います．

移植性に気を付けていなくても，GNU Makeだけをターゲットにしていて，なん とかして$(wildcard ...)を使用したい場合でも，処理されるファイル をAutomakeが正確に知っている必要がある場所がたくさんあることを知ってお くべきです．Automakeは$(wildcard ...)を展開する方法を知らないの で，これらの場所で使用することは不可能です．$(wildcard ...)は， Automakeが尊重するAC_SUBSTされている変数と比べてブラックボック スになります．

-Wportabilityフラグを使用すると，$(wildcard ...)の構成物 は警告されるはずです．