コグノスケ

バージョン管理システムとmake

前々から感じていたのですが、この2者は非常に相性が悪いと思います…。

• タイムスタンプに興味が無く、ファイルの中身しか気にしないバージョン管理システム
• タイムスタンプを気にして、ファイルの中身には興味が無いmake, autoconf/automake

例えばgit cloneしてきたリポジトリを ./configure && makeとすると、

• なぜかまたconfigureが走り始める
• 挙句の果てにautoconf/automakeが無いぞボケェ！と怒られる

という訳の分からない挙動をすることがあります。これはgit clone時にMakefile.amなどのタイムスタンプが変化してしまい、makeが勘違いして、ファイルが更新されたよ！依存するファイルを再作成しなければ！というアクションを起こしてしまうせいです。

これがもしtarballで展開したコードであればtaball作成時のタイムスタンプが復元されますので、この現象は起きません（tarballの作成者がヘマしていなければ、ですが）。

どうしたら良いか？

スマートな解決方法は「makeがファイルの変化を検知する方法を変える」ことです。恐らくmakeがファイルの変化を検知したい理由はたった1つで、

• AがBに依存しているとして、AはBより古い（＝再ビルド必要）か、新しい（＝再ビルド不要）か？

ただこれだけです。タイムスタンプを使うのは手段の一つに過ぎず、2ファイル間の新旧を判別できれば、タイムスタンプでなくても構わないはずです。

この日記のもとになったFacebookのエントリでは「タイムスタンプではなく、ファイルシステムが持っているブロックのハッシュ値が良いんじゃないか？」というコメントをいただきました。

前回のmake起動時と、今回のmake起動時の全ファイルのハッシュ値を記録しておけば、前回と変化したかどうか？はわかるし、ハッシュ再計算のコストがやや心配ですが、ファイルシステムが持っている値などを使えば抑えられる気がします。後は2ファイル間の順序関係を知る方法があれば、タイムスタンプの代わりになり得ると思います。

しかし、こんなの誰でも考え付きそうな話ですが、既に作られていたりしませんかねー…？

力ずくで解決する

とはいえ、現状ではmake以外の選択肢がありません。その場しのぎではありますが、力ずくで解決してみようと思います。

お題はgit cloneした後などタイムスタンプがメチャクチャになった状態でも、autotoolsが再実行されないようにするには、どうすれば良いか？です。

まずはautotoolsってそもそも何なのか？を調べてみます。適当にautotoolsを使っているプロジェクトを持ってきて、autoreconfを実行したときの動きを見ます。環境はDebian 8.0 (Jessie, i386) です。

$ autoreconf --force -v 2>&1 | egrep ^autoreconf
autoreconf2.50: Entering directory `.'
autoreconf2.50: configure.ac: not using Gettext
autoreconf2.50: running: aclocal --force★★こいつ★★
autoreconf2.50: configure.ac: tracing
autoreconf2.50: configure.ac: adding subdirectory component/empty to autoreconf
autoreconf2.50: Entering directory `component/empty'
autoreconf2.50: configure.ac: not running libtoolize: --install not given
autoreconf2.50: running: /usr/bin/autoconf --force★★こいつ★★
autoreconf2.50: running: /usr/bin/autoheader --force★★こいつ★★
autoreconf2.50: running: automake --force-missing★★こいつ★★
autoreconf2.50: Leaving directory `component/empty'
autoreconf2.50: Leaving directory `.'

結果を見た感じでは、実行されるツールは4つaclocal, autoconf, autoheader, automake です。

次にこれらのツールが再実行される仕組みを追うため、./configure実行後に生成されるMakefileを見てみます。

まずはaclocalから。

top_srcdir = .
srcdir = .

ACLOCAL_M4 = $(top_srcdir)/aclocal.m4

am__aclocal_m4_deps = $(top_srcdir)/configure.ac


$(ACLOCAL_M4):  $(am__aclocal_m4_deps)
        $(am__cd) $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)

$(am__aclocal_m4_deps):

ルールによればタイムスタンプが（新しい）aclocal.m4 > configure.ac（古い）という関係であれば、aclocalは再実行されません。

ちなみにm4ディレクトリに追加の .m4ファイルを入れている場合はam__aclocal_m4_depsにm4ディレクトリ内の .m4ファイルが並びます。従ってaclocal.m4 > configure.ac, (追加の .m4ファイル) という関係になります。

続けてautoconfです。

top_srcdir = .
srcdir = .

ACLOCAL_M4 = $(top_srcdir)/aclocal.m4

am__aclocal_m4_deps = $(top_srcdir)/configure.ac

am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
        $(ACLOCAL_M4)

$(top_srcdir)/configure:  $(am__configure_deps)
        $(am__cd) $(srcdir) && $(AUTOCONF)

ルールによればconfigure > configure.ac, aclocal.m4であれば、autoconfは再実行されません。

どんどん行きましょう。続けてautoheaderです。

top_srcdir = .
srcdir = .

ACLOCAL_M4 = $(top_srcdir)/aclocal.m4

am__aclocal_m4_deps = $(top_srcdir)/configure.ac

am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
        $(ACLOCAL_M4)

$(srcdir)/config.h.in:  $(am__configure_deps)
        ($(am__cd) $(top_srcdir) && $(AUTOHEADER))
        rm -f stamp-h1
        touch $@

最後にtouch $@ しているのが特徴的です。どうもautoheaderは生成した内容と、既にあるファイルの内容に差が無ければconfig.h.inを一切書き換えない、という妙な作りになっているらしく、このautoheader再実行ルールが適用されてもconfig.h.inのタイムスタンプが更新されない場合があります。

もしタイムスタンプが更新されないとmakeは毎回このautoheader再実行ルールを適用してしまいますので、無駄を避けるためにtouchしてconfig.h.inのタイムスタンプを強制的に更新し、次回以降のautoheader再実行を回避していると思われます。

他のツールは強制的に書き換えに行くんですが、なぜautoheaderだけ仕様が違うんだろう…？？

ま、それはさておき、ルールによればconfig.h.in > configure.ac, aclocal.m4であれば、autoheaderは再実行されません。

最後にautomakeです。

top_srcdir = .
srcdir = .

ACLOCAL_M4 = $(top_srcdir)/aclocal.m4

am__aclocal_m4_deps = $(top_srcdir)/configure.ac

am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
        $(ACLOCAL_M4)

$(srcdir)/Makefile.in:  $(srcdir)/Makefile.am  $(am__configure_deps)
        @for dep in $?; do \
          case '$(am__configure_deps)' in \
            *$$dep*) \
              echo ' cd $(srcdir) && $(AUTOMAKE) --foreign'; \
              $(am__cd) $(srcdir) && $(AUTOMAKE) --foreign \
                && exit 0; \
              exit 1;; \
          esac; \
        done; \
        echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign Makefile'; \
        $(am__cd) $(top_srcdir) && \
          $(AUTOMAKE) --foreign Makefile

ルールによればMakefile.in > Makefile.am, configure.ac, aclocal.m4であれば、automakeは再実行されません。

まとめ

今までのルールをまとめると、下記のようになります。

• aclocal: aclocal.m4 > configure.ac
• autoconf: configure > configure.ac, aclocal.m4
• autoheader: config.h.in > configure.ac, aclocal.m4
• automake: Makefile.in > Makefile.am, configure.ac, aclocal.m4

全部まとめるとタイムスタンプの時刻が（新しい）Makefile.in > Makefile.am, configure, config.h.in > aclocal.m4 > configure.ac（古い）であればautotoolは一切、再実行されない、と思われます。

要するに？

だからどうしたら良いんだ！俺は忙しいんだぞ！！という超短気な人のため、autotoolsの怒りを避けるためのビルド用のシェルスクリプトも付けておきます。

#!/bin/sh

# Prevent the autotools running...
touch aclocal.m4
touch config.h.in
touch configure

touch Makefile.am
touch src/Makefile.am
### もし他のサブディレクトリにMakefile.amがあればそれも
### find -name Makefile.am | xargs touchでも良いかもしれない

touch Makefile.in
touch src/Makefile.in
### もし他のサブディレクトリにMakefile.inがあればそれも
### find -name Makefile.in | xargs touchでも良いかもしれない

# Build
./configure
make

本当にこの節しか読まない人に注意しておくと、このスクリプトは現在のautotoolsの実装に依存していますので、将来autotoolsの実装が変わると、動かなくなる可能性が非常に高いです。動かなくなっても泣かないでください。

感想

こういうダーティーハックは個人的には面白いから好きですが、苦労の割には利益が無いと思いました。

数年もすればこの手のハックは動かなくなるので周りに迷惑ですし、後進の人がメンテしようにも意味不明で「シバくぞゴラァ！書いた奴出てこいやー！！」ってキレること請け合いです。