GNU Make 第3版 Robert Mecklenburg 著、矢吹 道郎 監訳、菊池 彰 訳 2005年12月 発行 304ページ ISBN4-87311-269-9 フォーマット Print 原書: Managing Projects with GNU Make, Third Edition
![O'Reilly Japan - GNU Make 第3版](https://cdn-ak-scissors.b.st-hatena.com/image/square/8c3a4781bf3d449110b92148bf229a872dd8114c/height=288;version=1;width=512/https%3A%2F%2Fwww.oreilly.co.jp%2Fbooks%2Fimages%2Fpicture4-87311-269-9.gif)
Go を使ってプロダクトを作る時、Makefile を使ってビルドを指定することが多いです。 理由としては、 バージョン情報などを埋め込むのに都合がいい 複数のバイナリを吐き出す時に都合がいい Go のビルドオプションを指定するのにいろいろあって整理しておきたい 事前にコードジェネレータで書き出す部分があり、それを考えると Makefile などで整理したい などなどです。なので今回はプロジェクトが大きくなっていく中でどういう Makefile の書き方をしているか、というのをご紹介しようと思います。 サンプルとして、今回のプロジェクトでは gRPC を使ったチャットサービスのサーバーとクライアントを作ることにします。リポジトリは https://github.com/rosylilly/gochat に置いておきました。 Step 1. バージョン情報を埋める 今回はサーバーとクライアン
2002 | 10 | 11 | 12 2003 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 2004 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 2005 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 2006 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 2007 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 2008 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 2009 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 1
CやC++で書かれたプログラムをMakeを使ってビルドする、というのはUnix/Linuxではよく行われていることだが、ちゃんとしたMakefileを書くのは意外と難しい。 例えば以下の3つのファイルからなるプログラムを考える。 foo.h: 関数fooの宣言がある。 foo.c: 関数fooの実装がある。 main.c: 関数fooを呼び出す。 /* foo.h */ void foo(int a); /* foo.c */ #include "foo.h" #include <stdio.h> void foo(int a){ printf("%d\n", a); } /* main.c */ #include "foo.h" int main(int argc, char **argv){ foo(10); return 0; } Makefileは例えば以下のように書ける。 PRO
https://github.com/google/kati kati について、ドキュメント書こう…と思っていたのですがなかなか進まないので、とりあえず日本語で書いてみることにしました。何書くかがあまり明確じゃないテーマなので、何書くか考えるのと英語考えるのを両方同時にやるのが少し大変で。 動機 kati は GNU make のクローンです。いずれ完全なコンパチになると嬉しいですが、なかなか難しいだろうと個人的には諦めています。用途に対して実用的ならば良いかなと。 動機としては、 Android platform のビルドシステムが、なかなかシュールな GNU make 黒魔術で構成されていて、 make が実際になんかしはじめるまでが遅かったので、そこを高速化したいというものでした。 ビルドシステムが遅いという時、まずだいたいヌルビルドとフルビルドの2点を考えます。ヌルビルドてのは生
オーバーロードされた関数の呼び出し(解決案) @pepshisoさんがさくっと答えてくださった. #include <stdio.h> void f(int) { puts("f:int"); } void f(double) { puts("f:double"); } template <class P> struct call_ { explicit call_(P p) : p(p) {} void operator()(void (*func)(P)) const { func(p); } P p; }; template <class P> call_<P> call(P p) { return call_<P>(p); } int main() { call(5)(f); call(5.3)(f); } なるほど, 引数と関数を同時に決めようとすると関数をキャストしないとあいま
_ scons http://blog.64p.org/entry/2012/07/11/224008 via https://plus.google.com/102550604876259086885/posts/AnEoGQexUcG scons なんて始まってもいねえよ! ってのが僕の感覚だなあ、たいしてしらないけど、必要じゃない機能ばっか充実しているという mukai さんのイメージに賛成する感じ。 scons に関していつも言ってる悪口に、ファイルが本当に変更された時にだけ依存関係をビルドしなおしてくれるという便利な機能がある。 これはどういうことかというと、 hello.c から hello.o と hello を作ったあと、 hello.c を touch してもビルドしなおしてくれないと。 stdio.h とか書きかえた時とか、そういう特殊なことしてるからわざわざ touc
基本メニュー トップ めらロ〜グ プラグインマニュアル NintendoDS Homebrew 掲示板 GBA/NDS Link NDS/GBA 技術情報 ・GBATek 日本語訳 ├GBA Ref.(完) ├NDS Ref.(翻訳中) └CPU Ref.(未整備) ・DSTek 日本語訳(完) ・NDSLIB 日本語訳(完) NDS 公開版ソフト ・BAKUDAN ・鏡音リン・レン ・NDS_TGM ・NDS_四川省 ・NDS_花札こいこい ・BGMファイラー ├BGM ドライバ(JP) ├BGM Driver(EN) ├MID ドライバ(JP) │└MIDDRV 開発 │------ ├NDS サウンド講座 └SMF2MML NDS ソフト部品 ・thfifo 日本語訳 ・電力制御 └PowerControl ・uITRON4
Chromium Notes: Ninja, a new build system ChromeをWindowsから移植し始めたとき、我々はSconsを使ってChromeをビルドしようとした。Sconsは、正しく動作して、使い方も簡単であった。しかし、開発を始めてすぐに、Sconsはとても遅いということに気がついた。ソースを実際にビルドし始めるまでに、40秒もかかるのだ。Sconsが全面的に悪いというわけでもない。Chromeのビルドは、たったひとつの実行ファイルのために、WebKitも含めて、30000ものファイルがあるのだ。 結局、私はLinuxビルドのために、単にMakefileを使うことにした。これは、我々のビルドシステムが、メタビルドシステム、すなわち、WindowsやMac用のビルドファイルを生成するビルドシステムだったから可能だったのだ。開発を進めるほどに、私はどんどんビルド
■ [Ruby] makeのコマンドライン表示を隠す なつかしい アイデアが採用された。 % make miniruby compiling ../ruby/trunk/main.c compiling ../ruby/trunk/dmydln.c compiling ../ruby/trunk/dmyencoding.c compiling ../ruby/trunk/version.c compiling ../ruby/trunk/dmyversion.c compiling miniprelude.c compiling ../ruby/trunk/array.c compiling ../ruby/trunk/bignum.c compiling ../ruby/trunk/class.c compiling ../ruby/trunk/compar.c compiling ..
仕組みが判ってしまえば Makefile は簡潔に書けます.$(CC) とか $@ とか $< なんて変数は使ったら負けです. 基本(その1) ソースコード hoge.c から 実行形式のバイナリ hoge を生成するMakefileは,以下のように書きましょう all: hogeこれだけです.これで $ make all とすると hoge が生成されます 重要な点は,間違っても all: hoge hoge: hoge.c $(CC) hoge.c -o hogeのようなMakefileを書かないことです.このようなMakefileでは #!/bin/sh CC=gcc $CC hoge.c -o hoge というようなシェルスクリプトと同程度の使い勝手しかありません. 基本(その2) ここで例えば-O3 を付けてコンパイルしたい場合や,-lm を付けてリンクしたい場合は以下のようにし
一時Makefileに凝っていました。Makefileの記述構文のなかに、「Lispに似た小さな関数型言語が埋め込まれているんだ」とか言ってましたよね。あれはまー、遊び半分なんだけど、このテの知識は、実際にMakefileを読み書きするときにも役にたちます。 過去のMakefile関係エントリーを読み返そうと思ったら、けっこう量があるし、紆余曲折があるんで、ここに整理してまとめておこうと思います。 内容: 参考資料 概念と用語 データ型 変数 関数 制御構造 画面出力と強制終了 ●参考資料 Makefileに関しては、次のエントリー群でゴタゴタと説明しています。 Makefileの書き方、その勘どころ Makefileの書き方:プログラミング言語Make プログラミング言語Make 補遺:引数付きの関数 Make 補遺の補遺:遊んでいるだけ Make言語で算術演算 <-- バカ! もっとも
GNU Make 第3版では、大きなプロジェクトで良くある、複数ディレクトリにまたがったプロジェクトを管理する場合に、ディレクトリ毎のMakeを再帰的に呼出す方法は推奨してません。また、.ccファイルの#include 依存関係をまずスクリプトで調査してMakefileを生成する方法も、かなりスマートでないということを知りました。ほんと、あたしってば物をしらない。 この無知さかげんは、Makefileを人の読むモノだと思っていなかったのが原因です。読まないで、自動でツールに作らせるから、とりあえず動けばOK。エレガントな makefileを作ろうと全然努力してないのだから、無知なのは当たり前よね。 さて、以下は本日の作業メモ。勉強のための模擬プロジェクトを作って GNU Make 第3版 を見ながらいろいろやってみました。こんなディレクトリ構成でビルドを行うmakefileです。 proj
GNU bashにもいろいろなバージョンがあります。最新は 3.2.* らしいです。1.14.* なんて古いのもまだ使えます。さて、次のfor文はシェルのバージョンにより挙動が違います。 $ for x in ; do echo $x; done GNU bash, version 3.00.15(1)-release (i686-redhat-linux-gnu) だと何も実行されませんが、エラーでもありません。GNU bash, version 2.04.0(1)-release (i686-pc-msys) だと、次のエラーになります。 sh: syntax error near unexpected token `;' この違いはMakefileを書くときも問題になります。 dothis: for x in $(LIST); do\ echo "$$x";\ done のように書い
カレントディレクトリに複数のXMLファイル(*.xml)があり、 これをHTMLに変換したい。 このときMakeを使って、更新されたファイルだけ変換するようにしたいがどうすればいいか。 前提条件 変換コマンドは /bin/toHtml とする( 標準入力からXMLを入れて、標準出力にHTMLが出力される ) xmlからhtmlに変換するときファイル名は拡張子以外は一致させる foo.xml → foo.html XMLファイルはどんどん増えていく 結論だけを知りたい方はここをクリック。 もしXMLファイル数が変化しないならば... もしXMLファイル数が変化しないならば、 Makefile に以下のように記述しておけばよい。 (変換対象となるファイルは foo1.xml foo2.xml foo3.xml) .SUFFIXES: .SUFFIXES: .xml .html .xml.htm
OMakeすごい。OMakeはマジですごい。 OMakeはGNU makeの代替品みたいなものなんだけど、正直なところこのツールの強力さはGNU makeと比べると失礼なくらいすごい。これのおかげで、「コード修正→ビルド→デバッグ→コード修正→・・・」のループの、ビルドにあたる作業がほぼ消え去った。 ファイルの依存関係の解析がとにかくすごい。よくあるユースケースなんかの場合、最小限の手間でほぼ完璧に依存関係を網羅して、よしなにビルドしてくれる。 とりあえず、はやみずが実際に使ってみたケースを例にとってそのすごさの一端を紹介しようと思う。 case study 論より証拠ということで、自分が OMake を試しにつかってみたケースを紹介する。C言語でスタティックライブラリを作っていて、それに加えて簡単なテストプログラムを書いている。 /include/ 以下にヘッダファイルが全部ある /sr
この章ではGNUプログラム用にMakefileを記述する際の慣習について書いてあります。 Makefileの一般的な慣習 Makefileには次の行を毎回含めるべきです。 SHELL = /bin/sh …というのは、環境からSHELL変数を受け継ぎ得るシステム上でのトラブルを避けるためです。(GNU makeではこれは全く問題になりません。) 別のmakeプログラムには非互換のサフィックスリストや暗黙ルールがあり、場合によって混乱をきたしたり動作不良を起こします。このため次のように、個々のMakefileで必要なサフィックスだけを明示的にサフィックスリストにセットするのが良策です。 .SUFFIXES: .SUFFIXES: .c .o はじめの行でサフィックスリストをきれいさっぱり除去して、次の行でこのMakefileで暗黙ルールに渡されてもいいサフィックスを全部書き込みます。 コマン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く