パスワードを忘れた? アカウント作成
334443 story
プログラミング

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

ストーリー by reo
Omake と Cmake を 部門より

ある Anonymous Coward 曰く、

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

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

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

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by iwadon (475) on 2011年06月10日 11時28分 (#1968037) ホームページ

    最近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]

    --
    DON
  • 今どき (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2011年06月10日 11時22分 (#1968029)

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

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

  • 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 のシステム全体をコンパイルできる以上、これで機能不足というケースはほとんど無いと思うが。
  • by Ryo.F (3896) on 2011年06月10日 10時14分 (#1967992) 日記

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

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

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

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

      • by Anonymous Coward

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

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

  • autotoolは? (スコア:1, 興味深い)

    by Anonymous Coward on 2011年06月10日 10時22分 (#1967998)

    ためしに手元のプログラムで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は? (スコア:1, 興味深い)

      by Anonymous Coward on 2011年06月10日 10時43分 (#1968009)
      autotoolはソースの数が多い時とかに威力を発揮するんじゃないかな

      んなもん、findして・・・とかいうのの行き着いた先がautotoolかと
      親コメント
      • by nyagy (17036) on 2011年06月10日 12時07分 (#1968070)

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

        親コメント
    • by shesee (27226) on 2011年06月10日 12時05分 (#1968068) 日記
      autotoolsは複数OS並行開発とか機能の切り分けとか動機がないとかえって複雑。もっともxcodeprojectも細かいところいじると邪魔臭さのコルモゴロフ複雑性はたいして変わらないかも
      親コメント
  • ×:make に変わる (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2011年06月10日 10時27分 (#1968003)

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

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

    • Re: (スコア:0, オフトピック)

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

      --
      Hiroki (REO) Kashiwazaki
  • 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"と
    を1つにまとめたいです。教えて下さい!

    --
    love && peace && free_software
    t-nissie
    • by iwadon (475) on 2011年06月10日 11時21分 (#1968028) ホームページ

      こういうことでしょうか? 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] で説明されています。

      --
      DON
      親コメント
      • ありがとうございます。

        紹介していただいた "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
        親コメント
  • by Angelica (23122) on 2011年06月10日 11時18分 (#1968025) 日記

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

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

  • by reo (4042) on 2011年06月10日 11時27分 (#1968035) 日記

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

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

    --
    Hiroki (REO) Kashiwazaki
    • by Anonymous Coward

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

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

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

      • Re:LaTeX + Omake (スコア:2, 興味深い)

        by Anonymous Coward on 2011年06月10日 17時59分 (#1968289)

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

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

        親コメント
      • by reo (4042) on 2011年06月10日 19時33分 (#1968335) 日記

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

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

        --
        Hiroki (REO) Kashiwazaki
        親コメント
  • by greentea (17971) on 2011年06月10日 12時56分 (#1968110) 日記

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

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

    --
    1を聞いて0を知れ!
    • by Anonymous Coward
      VS2008、VS2010のcsprojとかはmsbuildが通るXMLなんで、可読性は低くはないですね。 まあ、nantとかと同じくらいかな。
  • TracLightningに統合されてるところから知った人間だが、まだ使ったことない。

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

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

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

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

  • by nyagy (17036) on 2011年06月12日 2時01分 (#1968867)

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

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

  • by Anonymous Coward on 2011年06月10日 11時11分 (#1968019)
    antのxml記法って自由度の割に可読性が高いよね
    ただ、そこにスクリプトivyとかいれると腐っていく。

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

    #
    # mavenをbuildツールとして使うバカがいるがあれば、
    # buildもできるがプロジェクト管理ツールとしてみてくれ
    #
  • by Anonymous Coward on 2011年06月10日 11時24分 (#1968033)
    というビルドツールを作った夢を見たのさ
  • by Anonymous Coward on 2011年06月10日 12時12分 (#1968073)
    makeといってもいろいろあるからな。GNU makeみたいな芋みたいのもあるし。
  • by Anonymous Coward on 2011年06月10日 13時49分 (#1968149)
    そんなものは、ない
  • by Anonymous Coward on 2011年06月10日 16時22分 (#1968253)
    Makefileを自動生成するだけですが、

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

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

    ヘタレなので、一からMakefileは書けません。
  • by Anonymous Coward on 2011年06月10日 20時43分 (#1968360)
    エリック・レイモンド,おすすめの SCons なんてのもありますね. http://www.scons.org/ [scons.org]
  • by Anonymous Coward on 2011年06月10日 21時06分 (#1968373)

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

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

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

    • by njt (4968) on 2011年06月11日 17時36分 (#1968705) 日記

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

      親コメント
    • by uratan (26577) on 2011年06月16日 0時35分 (#1971028) ホームページ 日記
      C の場合オプション的マクロ定義をコマンドラインの引数で与えることも
      多いわけで、そう考えるとコンパイラのオプションは実はソースコードな
      わけで、バージョン管理されたり、バージョン毎の違いを抽出するために
      diff で差分が取り出せなければいけないわけで、そうなるとそういった
      設定を隠蔽しがちな IDE は やはりよろしくないと思う私も古い人間でして、
      やっぱり Makefile での管理がいいですね。
      親コメント
  • by Anonymous Coward on 2011年06月11日 1時01分 (#1968478)
    makeの目的のひとつに、差分だけビルドしなおしてリビルドを高速化するってのがあるじゃない?

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

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

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

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

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

    あ、それがIDEってやつですか、そうですか。
  • by Anonymous Coward on 2011年06月11日 1時54分 (#1968493)
    関連会社の人が使ってて自分のところでmakeするとき戸惑いましたが...
typodupeerror

※ただしPHPを除く -- あるAdmin

読み込み中...