スラッシュドットに聞け: make に代わるビルドツール、おすすめは ?

ある Anonymous Coward 曰く、

OSS のビルドでは、多くの場合 make を利用することが多い。Wikipedia の make の項目でも「UNIX 系ソフトウェアは、ソースコードの形で配布されることが多いが、そのビルド作業にはほぼ必須のツールといえる」と述べられている make だが、近年ではこれに代わるツールも多く登場しており、たとえば Visual Studio では make をまったく使わずにビルドを行うことができる。

もちろん、make は柔軟であり有用なツールではあるのだが、問題は (C++ のように) 記述に自由度が高すぎて、Makefile を作成するユーザーの技量によっては読解が激しく難しいものができてしまう点だ。また、大規模なソフトウェアの場合サブディレクトリを作ってそれぞれに Makefile を作成する、というのが一般的だが、配置方法や内容によってはこれまた訳の分からない Makefile が散乱することになってしまう。

「誰が使っても比較的安定した品質で管理できるビルドツール」というものは存在するのだろうか ? それとも、皆おとなしく make を使っているのだろうか ?

Ninja build system

[iwadon (475)]

最近Ninjaというビルドシステムを触っています。
http://martine.github.com/ninja/manual.html [github.com]
Makefileに相当する.ninjaファイルの書式が意外と読みやすく書きやすかったことと、並列ビルドがデフォルトな所が気に入ってます。Makefileを手書きするような人ならすぐに慣れるのではないかと思います。
以下参考リンク:
http://osdn.jp/magazine/11/02/09/0832255 [osdn.jp]
http://d.hatena.ne.jp/karasuyamatengu/20110207/1297108418 [hatena.ne.jp]
http://cpplover.blogspot.com/2011/03/blog-post_05.html [blogspot.com]

--
ＤＯＮ

Re:

[Anonymous Coward]

存在を知らなかったので情報ありがたいです。

ところで
> 高速なことからNinjaと名付けたという。

高速=忍者？

Re:Ninja build system

[iwadon (475)]

製作者のイメージによるとそうなんでしょうね(実際のところは知りませんが)。

--
ＤＯＮ

Re:

[Anonymous Coward]

> 高速=忍者？

目にもとまらぬ早業で～♪

Re:

[Anonymous Coward]

カワサキのバイク乗りなんだろ

今どき

[Anonymous Coward]

今どきmakeを使っている奴ってMAKE組だよねー。

・・・うん。言ってみたかっただけなんだ。ごめん。orz

プログラミング言語 make

[Technical Type (3408)]

Windows を使いだしたときは「make もコンパイラも無い OS なんて、何の使い道があるのか」と思ったが、無償で使える Borland C++ Compiler 5.5 で日本語は通るので、文章を書く程度ならこの make や cpp で間に合っている。変遷を経た今もダウンロード登録フォーム [embarcadero.com]があるね。

自分で見返すのも嫌になるぐらい長たらしい手順書を、共通部分もあるが微妙に内容を変えた「技術者向け」「一般利用者向け」「他部署の参考用」と出力を分ける時などは HTML のタグブラウザで直接手順を書いて、 #ifdef とかで条件も分けて、Makefile は cpp 通して複数のターゲット文章を作るように書いて、make して、HTML は Web 公開用に、それを Word で読ませて PDF に変換して配布用とか、作り分けてる。最後に "make up" と打てば複数の文書保管サーバーにアップロードされるようにしてある。

今のところは make で間に合っているというか…習得に時間を掛けたせいもあって make が好きだったりするのだが、確かに、後で自分で Makefile 見ても分かりづらい場合がある。それでコメント書くようにしているけど。Makefile 生成ツールとかは使わないな。そもそも Makefile が手で書けない人間向けのお助けツールだが、人間が書くのよりダメな Makefile を生成するし、ドキュメント作成のための Makefile の生成などは無理だし。

make はツールというより、Makefile 自体が、手順を自動化するプログラミング言語だと思えばいいのでは。だから、使用されている「プログラミングテクニック」が判らない人に読解できないのは当たり前かと。でもそれは「make を知らない人の責任」であって、「誰が使っても」できる訳ではないという理由で make に「責任取れ」「もっと分かりやすくなれ」というのも。

より優れたツールが出れば、それに負けたツールは自然と消える物だ。例えば make は FreeBSD のシステム全体をコンパイルできる以上、これで機能不足というケースはほとんど無いと思うが。

誰が使っても

[Ryo.F (3896)]

「誰が使っても」ってのは、まあ無理なんじゃない？

最近は、IDEとかフレームワークとかがやってくれるもんじゃないんですか？古い人間なのでよく知らんのですが。

Re:

[Anonymous Coward]

古い人間だしチームで大規模スシテムの開発などやってないので、すべてのソースをリビルドしてますが。　それで長時間待たされるわけでも無いので.........　
バージョン管理にはrcs/diffを使ってる古い古い人間です。　テキスト以外のリソースを管理する必要も無いので.........

Re:

[Anonymous Coward]

UNIXなんてコンソールアプリをパイプでつなげて目的の作業を達成する慣わしがあるんだから、全コンパイルでも問題無いようにビルド単位を小さくすりゃいいんだよ。

Re:

[Anonymous Coward]

「make に代わるビルドツール」の開発動機って、多くの場合は「UNIX のシェルに依存しない」か
「(リ)ビルドにかかる時間」のどちらかなんですよね。
UNIX っぽい環境での小規模プロジェクトなら、標準的という点でやっぱり make でいいんじゃないかな。
Makefile の可読性といっても、結局はシェルスクリプトが読めるかということだし…
「使う」がダウンロードしてきたソースコードをビルドするだけなら、別に読めなくてもよいという割り切りもあるかと。
あ、悪意のあるコマンドが含まれていないかどうかくらいは確認できた方がいいかもですね。

自分で書いたコードをビルドするのに「使う」分には、いろいろ試してみて使い易いのを選べばよいと思います。

autotoolは？

[Anonymous Coward]

ためしに手元のプログラムでautoscan⇒mv configure.scan configure.in⇒configure.in編集⇒Makefile.am作成⇒touch NEWS README AUTHORS ChangeLog⇒aclocal; autoheader; automake -a -c; autoconf⇒./configureしてみたら想像以上に面倒くさいことにﾜﾛﾀ

手書きでMakefile書いた方が早い

Re:autotoolは？

[Anonymous Coward]

autotoolはソースの数が多い時とかに威力を発揮するんじゃないかな

んなもん、findして・・・とかいうのの行き着いた先がautotoolかと

Re:autotoolは？

[nyagy (17036)]

古い人間な私はmkmfを愛用してましたが、最近はめっきり聞かなくなりました。
ま、私もCで開発することがなくなったのでMakefileを書くこともなくなったのですが。

Re:autotoolは？

[shesee (27226)]

autotoolsは複数OS並行開発とか機能の切り分けとか動機がないとかえって複雑。もっともxcodeprojectも細かいところいじると邪魔臭さのコルモゴロフ複雑性はたいして変わらないかも

×：make に変わる

[Anonymous Coward]

×：make に変わる
○：make に代わる

「変わる」じゃ結局 make 使うことになっちゃうよ

Re:

[reo (4042)]

うっぷす、ご指摘 thx です。修正しました。

--
Hiroki (REO) Kashiwazaki

Rubyのrakeを使っているけど

[t-nissie (8647)]

Rubyのrakeを使っているけど、かっこよく書くに
は適当なライブラリをrequireしなきゃいけなかっ
たり、疑問があってもどのドキュメントを読めば
よいのかいまいちわからなかったりでmakeのほう
がよいなぁと思ってしまいます。

たとえば今はGNU make風な

%.ps: %.F
    a2ps --prologue=color --portrait --columns=1 \
      --margin=3 --borders=off\
      -f 10.5 --pretty-print=for90-free -o $@ $<

ってのをどうrakeで書けばよいか調べがつきません。
具体的には http://ulmul.rubyforge.org/svn/ulmul/trunk/Rakefile [rubyforge.org]
のdesc "Create index.en.html"とdesc "Create index.ja.html"と
を１つにまとめたいです。教えて下さい！

--
love && peace && free_software
t-nissie

Re:Rubyのrakeを使っているけど

[iwadon (475)]

こういうことでしょうか？ ruleというところがMakefileのパターンマッチに相当すると思います。

task :default => :build

task :build => ['a.o', 'b.o', 'c.o']

rule '.o' => ['.c'] do |t|
    sh 'cc', '-c', '-o', t.name, t.source
end

くわしくはRakeのドキュメントやdoc.rubyrake.orgのドキュメントをご覧ください。なお、上記ruleは http://docs.rubyrake.org/user_guide/chapter03.html [rubyrake.org] で説明されています。

--
ＤＯＮ

Re:Rubyのrakeを使っているけど

[t-nissie (8647)]

ありがとうございます。

紹介していただいた "rule" を使おうと Rakefile を眺めていたら、
結局こんな解決策になりました。RakefileもRubyスクリプトなんですね。

BEFORE:

desc "Create index.en.html"
file "index.en.html" => ["bin/ulmul2html5", "README-en", "ulmul2html5.css", "google-code-prettify/src/prettify.css",
                         "google-code-prettify/src/prettify.js", "lib/ulmul.rb"] do |t|
  sh "ruby -I lib #{t.prerequisites[0]} -n 'Takeshi Nishimatsu' -s #{t.prerequisites[2]} -s #{t.prerequisites[3]} \
      -j #{t.prerequisites[4]} -l en #{t.prerequisites[1]} | \
      sed -e 's%</h1>%</h1><div class=\"navi\">[<a href=\"index.en.html\">English</a>/<a href=\"index.ja.html\">Japanese</a>]</div>%' > #{t.name}"
end
 
desc "Create index.ja.html"
file "index.ja.html" => ["bin/ulmul2html5", "README-ja", "ulmul2html5.css", "google-code-prettify/src/prettify.css",
                         "google-code-prettify/src/prettify.js", "lib/ulmul.rb"] do |t|
  sh "ruby -I lib #{t.prerequisites[0]} -n 'Takeshi Nishimatsu' -s #{t.prerequisites[2]} -s #{t.prerequisites[3]} \
      -j #{t.prerequisites[4]} -l ja #{t.prerequisites[1]} | \
      sed -e 's%</h1>%</h1><div class=\"navi\">[<a href=\"index.en.html\">English</a>/<a href=\"index.ja.html\">Japanese</a>]</div>%' > #{t.name}"
end

AFTER:

["en", "ja"].each{|lang|
  desc "Create index.#{lang}.html"
  file "index.#{lang}.html" => ["bin/ulmul2html5", "README-#{lang}", "ulmul2html5.css", "google-code-prettify/src/prettify.css",
                           "google-code-prettify/src/prettify.js", "lib/ulmul.rb"] do |t|
    sh "ruby -I lib #{t.prerequisites[0]} -n 'Takeshi Nishimatsu' -s #{t.prerequisites[2]} -s #{t.prerequisites[3]} \
      -j #{t.prerequisites[4]} -l #{lang} #{t.prerequisites[1]} | \
      sed -e 's%</h1>%</h1><div class=\"navi\">[<a href=\"index.en.html\">English</a>/<a href=\"index.ja.html\">Japanese</a>]</div>%' > #{t.name}"
  end
}

--
love && peace && free_software
t-nissie

Re:Rubyのrakeを使っているけど

[iwadon (475)]

はい、RakefileもRubyスクリプトです(いわゆるDSL?)。
Ruby DSLでググるとRakeの話が出てくるほどなので、典型的な例なのかもしれません。

--
ＤＯＮ

ソフト任せ

[Angelica (23122)]

本文にもある通り、IDE任せにしてますねー。
emacs、vi、メモ帳、edlin、秀丸、その他諸々何を使って書いてもいいので、最終的にはIDEに放り込んでビルド通るように設定してくれ、という感じです。

依存関係がめちゃくちゃなプロジェクトファイルだと面倒ですけど、それはまあmakeだってそうだし。

LaTeX + Omake

[reo (4042)]

論文はもとより提案書や仕様書、出張報告書なども基本的に LaTeX で書く程度に TeX Love な僕ですが (だが TeX 練度は恥ずかしいほどまでに低い) 、数年前に OMake つかって LaTeX コンパイルしたら簡単すぎて身長が5cm伸びた [hatena.ne.jp]なる記事を読んで以来、特に Mac 環境では LaTeX での文書執筆に OMake なしでは生きていけないぐらいになっています (Windows での DVIOUT みたいな DVI ビューアがあればいいんですが) 。

# DVIOUT はウィンドウをアクティブにするだけで再描画してくれたんですが、
# 僕の知る範囲では Mac 用 DVI ビューアでそういうのはないような。
# あったら教えてください。

--
Hiroki (REO) Kashiwazaki

Re:

[Anonymous Coward]

最終生成物をdviではなく、dvi2pdfmxを使ってpdfに変換しています。
pdfはMac標準のプレビューで表示します。
プレビューはファイルの更新を関知すると自動的に再描画してくれます。

OMakeがpdfまで面倒をみてくれるかどうか知りませんが、私はこれで確認しています。
ちなみにビルドには昔ながらのmakeを使っています。

# ただPSの画像があるとdvi2pdfmxの処理速度がそこでがた落ちになるのが少し難点

Re:LaTeX + Omake

[Anonymous Coward]

英語圏では既に DVI を経由せず直接 PDF を生成する pdflatex が事実上の標準になっていますので、今後の DVI ビューアのメンテナンスはあまり期待できませんね。

日本人でこの辺を頑張ってくれる若い人が出てきてくれるといいんですけど……

Re:LaTeX + Omake

[reo (4042)]

あー、同じですね。OMake は pdf まで面倒を見てくれますし、TeX ファイルの更新を検出して自動でコンパイル → pdf 変換までやってくれるので大変便利。僕は画像を eps で作っていたのですが、dvipdfmx の eps 変換処理で非常に長い時間を要してしまうので、このごろは画像を pdf で作っています。が、そうすると今度は platex によるコンパイルで時間を要するんだよなあ……。

Mxdvi [keio.ac.jp] というソフトがあるのを知ったのですが、これが更新検出 (あるいはウィンドウのアクティブ化) & 自動再描画を行ってくれるかどうかはまだ調べてません。

--
Hiroki (REO) Kashiwazaki

読解が困難

[greentea (17971)]

もちろん、make は柔軟であり有用なツールではあるのだが、問題は (C++ のように) 記述に自由度が高すぎて、Makefile を作成するユーザーの技量によっては読解が激しく難しいものができてしまう点だ。

テキストで開こうとしたことがないから分からないのだけど、Visual StudioとかのIDEが作るビルド用ファイルの場合、可読性が高いの？

--
1を聞いて0を知れ!

Re:

[Anonymous Coward]

VS2008、VS2010のcsprojとかはmsbuildが通るXMLなんで、可読性は低くはないですね。 まあ、nantとかと同じくらいかな。

Mavenは?

[M-FalconSky (8868)]

TracLightningに統合されてるところから知った人間だが、まだ使ったことない。

サーバサイドで全部勝手にやってくれるなら便利なんだけど、アレどんなもんなのかなー？

# 今までのコメントから見ると利用率は低そうだ
# そもそもmake代用じゃない、か?

--
M-FalconSky (暑いか寒い)

cmake & ccmake

[sync.neo (16796)]

あるオープンソースなコードをコンパイルするのに cmake [cmake.org] & ccmake というツールを使わざるを得なかったことがあります。 基本的にはマルチプラットフォームに対応した Makefile の自動生成ツールなんですが、これがとても複雑で、コードをコンパイルするまでにえらく苦労しました。 自動生成されるビルドツリーと Makefile は複雑怪奇でどれだけ時間をかけても読むことができず、コンパイラとリンカのスイッチを変更するだけの作業に何時間もかかる始末。 特に ccmake は条件を変えると既存の設定が全部破棄される場合があって、何度泣かされたことか。こんなもの使うくらいなら Makefile 手書きの方がどれほど楽か、と思いました。

ちゃんと使えば有用なツールなのでしょうかね？ もし誰か使ったことがある方がいらっしゃったら、感想・意見を聞きたいです。

makeの優位性

[nyagy (17036)]

みんな手が覚えてるってのがあるんじゃない？後発ツールがここに付け入るのは、なかなかに難しいと想像。

# 「お前はこれまでmakeした数を覚えているのかっ!?」

apache ant

[Anonymous Coward]

antのxml記法って自由度の割に可読性が高いよね
ただ、そこにスクリプトivyとかいれると腐っていく。

フルセットのantがほしいぜよ！

#
# mavenをbuildツールとして使うバカがいるがあれば、
# buildもできるがプロジェクト管理ツールとしてみてくれ
#

Re:apache ant

[Anonymous Coward]

XML使う時点でうんこだと思う。

Re:apache ant

[Junos (14052)]

yaml -> xml変換プロセスを入れればすこしはましになるかな?

Re:

[Anonymous Coward]

java環境ではantなんだろうけど、他環境に浸透してこないってことはmakeの代替にはならんのだろうなと。ant登場時は期待したんだけどねえ。
*BSDな人たちは、いまだにmakeとgmakeの違いに苦労してるようで・・・

kachi

[Anonymous Coward]

というビルドツールを作った夢を見たのさ

Re:kachi

[okky (2487)]

徒歩(かち)で一歩一歩あるくがごとく、手でコンパイルしていくのさー

# それなら負け(make)でいいです。

--
fjの教祖様

Re:

[Anonymous Coward]

kachi;kachi yamaが流行る予感

makeといっても

[Anonymous Coward]

makeといってもいろいろあるからな。GNU makeみたいな芋みたいのもあるし。

結論

[Anonymous Coward]

そんなものは、ない

Qtアプリケーションならqmake

[Anonymous Coward]

Makefileを自動生成するだけですが、

1. 1つのディレクトリにヘッダファイルとソースファイルを用意する。
2. qmake -projectで[ディレクトリ名].proを生成する。
3. 必要なら[ディレクトリ名].proファイルを編集する。例えば、デバッグできるようにするには、"CONFIG += debug"を追加する。
4. qmakeでMakefileを作る。
5. make

ファイルの追加をする場合は2.もしくは3.から。再ビルドしたいだけなら、makeをすれば変更したところだけが再ビルドされます。

ヘタレなので、一からMakefileは書けません。

Re:Qtアプリケーションならqmake

[t-nissie (8647)]

その昔、xmkmfってのがあってだな…（今もあるけど）
キーワードはImakefileとimake。

--
love && peace && free_software
t-nissie

Re:

[Anonymous Coward]

qmakeが出たというのに、これまでcmakeの話題なし?

Re:

[Anonymous Coward]

>> qmakeが出たというのに、これまでcmakeの話題なし?

つ「部門名」

SCons

[Anonymous Coward]

エリック・レイモンド，おすすめの SCons なんてのもありますね． http://www.scons.org/ [scons.org]

IDE

[Anonymous Coward]

GUIやメニュー項目でコンパイルオプションやビルド条件等を指定していく方式だと、
結局いまのビルド条件はどうなっているのか、ということを一覧にしにくいし、
メニュー項目をいじったときの副作用などを全部理解してないと、たとえば
メニュー項目を指定する順番が違うと違ってしまうとか、ソースファイルに勝手に
変更が加わってしまうとか、だからソースファイルに手を加えた後だと競合して
おかしなことになるとか、とにかくややこしすぎると感じます。

テキストファイルの内容で指定するほうが、そのファイルの内容が全てなので、
とっても簡潔で単純で分かりやすいと思います。

古い人間なのでそう思うのかも知れません。

Re:IDE

[njt (4968)]

一種類の言語だけで書けるようなプロジェクトならIDEが良さそうだけれど
一部はCとか、一部はasmとかだとやっぱりmakeを使った方がハマらなさそう。

Re:IDE

[uratan (26577)]

C の場合オプション的マクロ定義をコマンドラインの引数で与えることも
多いわけで、そう考えるとコンパイラのオプションは実はソースコードな
わけで、バージョン管理されたり、バージョン毎の違いを抽出するために
diff で差分が取り出せなければいけないわけで、そうなるとそういった
設定を隠蔽しがちな IDE は やはりよろしくないと思う私も古い人間でして、
やっぱり Makefile での管理がいいですね。

理想

[Anonymous Coward]

makeの目的のひとつに、差分だけビルドしなおしてリビルドを高速化するってのがあるじゃない？

しかしながら、Android位の巨大なプロジェクトになると、Makefileをパースするだけで時間が掛かるんだよねぇ。もうそろそろ、"プレコンパイルドMakefile"みたいなものが出てきても良いと思うのよ。

ソースの依存関係を知っているのはコンパイラだけなので、gcc -MMDとかやって依存関係を吐かせるじゃない？

しかしながら、config.hのようなものが更新されると、必要のないものまでビルドされちゃって、結局時間が掛かるんだよねぇ。もうそろそろ、makeはコンパイラと合体して、依存関係を綿密にやりとりすべきだと思うのよ。

そもそも、更新されたファイルについて一番よく知っているのは、SCMじゃない？

いっそのこと、SCMもmakeに合体してしまえば、更新ファイルのスキャンも簡単になるし、ビルド成果物も同じリポジトリ上で管理してしまえば、分散ビルドも簡単にできると思うのよ。

あ、それがIDEってやつですか、そうですか。

omake?

[Anonymous Coward]

関連会社の人が使ってて自分のところでmakeするとき戸惑いましたが．．．