link もっと前
   2015年 6月 5日 -
      2015年 6月 5日  
link もっと後

link 未来から過去へ表示(*)
link 過去から未来へ表示

日々

link permalink

バージョン管理システムと 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 が起動するツール群
$ 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 から。

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 の方が新しければ aclocal は再実行されません。

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

続けて autoconf です。

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 です。

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 です。

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 の怒りを避けるためのビルド用のシェルスクリプトも付けておきます。

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 の実装が変わると、動かなくなる可能性が非常に高いです。動かなくなっても泣かないでください。

感想

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

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

[編集者: すずき]
[更新: 2015年 6月 7日 03:20]
link 編集する

コメント一覧

  • hdk 
    なんでタイムスタンプを覚えてくれないんだーって、某電子掲示板の Git スレ等で時々湧いてきた (くる?) 話題です。本来これは make の仕組みと相性がよいもので、必ず現在時刻に置き換わるおかげで、git blame 等過去のバージョンを引っ張り出した時に、差分があるファイルを確実に再コンパイルできます。

    Makefile.am のタイムスタンプが変化して、無駄な configure が走る、というのは、そもそもバージョン管理の対象にすべきでないファイルを入れている感じがします。Makefile の : の左側に来るファイルを入れても、: の右側とのタイムスタンプの差は管理できないので、例えばソースコードから生成されるオブジェクトファイルを入れといたからコンパイル時間短縮できますーとなるとは限りません。マージ後 make せずにコミットすれば、正しくないオブジェクトファイルがコミットに残ってしまうかも知れません。Makefile.am で言えば、Makefile.am がマージで変更されたのに autoreconf せずに commit してしまうと、それを checkout した人が首を傾げることになります。

    プロジェクトによっては、configure がリリース版 tarball のみにあって、バージョン管理下には入ってなくて latest を試す時には自分で autogen.sh を走らせるタイプのものがありますが、そういうのが正しい解なのかなと思います。 
    (2015年06月07日 09:54:03)
  • すずき 
    >hdk さん

    なるほど Git で差分更新したときのことはあまり考えていませんでした。今回の話は git clone のときだけの問題ですね。

    おっしゃるように、一般の利用者はリリースバージョンの tarball を使って、開発者は git clone を使おう。開発者なら autoreconf なり autogen.sh を使って configure を生成するくらいはやろう、という割り切り方は有りだと思います。実際それで回っているプロジェクトもあるわけですし。

    ただ、それで万事解決か?というと、そんなこともないよなーと思うわけで…。

    利用者にとっては tarball を使えと言われても、公開されていないバージョンだとお手上げですし、開発者にとっては「チェックアウトした状態でビルド&テストが通る」ってのは一番とっつきやすくてありがたいように思います。
     
    (2015年06月07日 11:51:31)
open/close この記事にコメントする



link もっと前
   2015年 6月 5日 -
      2015年 6月 5日  
link もっと後

管理用メニュー

link 記事を新規作成

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDF ファイル RSS 1.0
QR コード QR コード

最終更新: 7/17 22:53

カレンダー

<2015>
<<<06>>>
-123456
78910111213
14151617181920
21222324252627
282930----

最近のコメント 5件

  • link 18年07月04日
    すずき 「NEON にも対応してみましたが、やはり...」
    (更新:07/11 21:26)
  • link 18年05月30日
    すずき 「情報ありがとうございます。PT2 2枚差...」
    (更新:06/02 17:27)
  • link 18年05月30日
    通りすがりですみませ... 「私のPC(Win10)ではB−CAS1枚...」
    (更新:06/02 16:42)
  • link 18年05月20日
    すずき 「数えたことはありませんが Windows...」
    (更新:05/22 22:26)
  • link 18年05月20日
    hdk 「Linux も、先日の Meltdown...」
    (更新:05/21 22:55)

最近の記事 3件

link もっとみる
  • link 18年07月17日
    すずき 「[エアコンが臭い] 「エアコンの嫌なニオイが完全に消えた」 "窓全...」
    (更新:07/17 22:53)
  • link 18年07月16日
    すずき 「[AArch64 向け Linux 開発環境の構築 その 2] そ...」
    (更新:07/17 22:46)
  • link 18年07月07日
    すずき 「[Android と MPEG2-TS その 3] その 1、その...」
    (更新:07/17 22:46)

こんてんつ

open/close wiki
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報