Makefileの書き方に関する備忘録 その3 - minus9d's diary
この記事は続き記事です。目次→Makefileの書き方に関する備忘録 - minus9dの日記 変数に何を入れるか .cから.oへのコンパイルには以下の暗黙的なルールが使われる。 $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c -o $@.ccから.oへのコンパイルには以下の暗黙的なルールが使われる。 $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c -o $@これらの変数には、以下のルールに従って値を入れるのがよさそう。 $(CC): Cのコンパイラを指定。cc, gcc, armcc(ARM用のコンパイラ)など $(CXX): C++のコンパイラを指定。g++など $(CPPFLAGS): C/C++共通で指定したいフラグを入れる。-I/usr/include, -O2など $(CFLAGS):
C/C++中規模プロジェクトのための超シンプルなMakefile | POSTD
私は多くの小規模プロジェクトで Make を使ってきましたが、より大きな規模のプロジェクトになると、それは非常にうんざりするようなものでした。最近までは、自分のビルドシステムに行いたいことが4つあったのですが、Makeでの方法が分かりませんでした。 out-of-sourceビルド（オブジェクトファイルが、ソースとは分離されたディレクトリにダンプ出力されます） 自動生成される（かつ正確！）ヘッダの依存関係 オブジェクト／ソースファイルのリストの自動的な決定 インクルードディレクトリのフラグの自動生成 以下にこれらの全てを行える、C、C++、およびアセンブリで動作するシンプルなMakefileを紹介します。 MAKEFILE TARGET_EXEC ?= a.out BUILD_DIR ?= ./build SRC_DIRS ?= ./src SRCS := $(shell find $(S
make の ifdef はわかりにくい
シェルにおいて $ FOO= とすると、シェル変数 FOO は空ではあるが、定義はされている。 変数 FOO を未定義にするには $ unset FOO としなければならない。 つまり、シェルスクリプトで、「変数が空」であることと、「変数が未定義」であることは明確に違う。 一方、make においてはこのあたりが紛らわしいというか、非常にわかりにくいと思うので、整理しておきたい。 make には ifdef という構文があるが、これの挙動を見てみる。 （実験1） 以下の内容の Makefile を用意する。 FOO= all: ifdef @echo FOO is defined. else @echo FOO is NOT defined. endif 実行すると以下のようになる。 $ make FOO is NOT defined. FOO= のように、空文字を代入した場合、 ifdef
GNU makeとinclude - kaityoの日記
ずっとmakefileでわからなかったことがあったのだが、今日まじめに調べてようやく分かった。 makefileでソースの依存関係をいちいち手書きするのが面倒なので、 SRC=$(shell ls *.cc) dep: g++ -MM -MG $(SRC) >makefile.depend というルールを作っておき、makefileの最後で -include makefile.depend としておく。こうすると $ make dep とやればmakefile.dependができる。さて、makefile.dependが古かったり存在しなかったりした場合に自動的に作りたくて、 SRC=$(shell ls *.cc) makefile.depend: g++ -MM -MG $(SRC) >makefile.depend -include makefile.depend とかやっていると、
第 4 章 make ユーティリティ > 依存関係の検査 : make とシェルスクリプト
依存関係の検査 : make とシェルスクリプト 単純な処理の場合には、ソフトウェアの構築にシェルスクリプトを使用して整合性を保つことができますが、ソフトウェアプロジェクトの構築では多くの場合スクリプトは適していません。プログラムまたはオブジェクトモジュールのうちの 1 つだけが変更されている場合に、単純なスクリプトを使用してすべてのプログラムまたはオブジェクトモジュールをコンパイルするのは効率がよくありません。また、スクリプトを繰り返し編集しているうちに、整合性を保つことができない場合があります。再コンパイルが必要なモジュールだけを再コンパイルするスクリプトを記述することはできますが、それには make を使用する方が適しています。 make を使用すると、構築するファイルとその構築方法を簡潔かつ構造的に記述することができます。make は、依存関係の検査という仕組みを使用して、各モジュ
Makefileでソース、ヘッダファイルの依存関係を処理 - 余白の書きなぐり
大規模なC言語プログラムでは、ソースやヘッダファイルが複雑な依存関係を持つため、それらを自動解決してくれるMakefileが欲しくなる。 欲望を具体化すると ソース、ヘッダ、オブジェクトファイルは異なるディレクトリに入れたい 依存関係を認識し、更新すべきオブジェクトファイルを自動検出 新しいソース、ヘッダファイルを作成した際、Makefileを書き換ずに済む 他のプロジェクトにも使いまわせる汎用性 Makefile自体が短く、保守しやすい だいぶ贅沢だが、頑張ってMakefileをこしらえたので、得られた知見を忘れないうちにまとめておく。 以前書いたMakefile文法ミニマムも参考にしてくれ。 ディレクトリ構成 root +----src/ | +---- main.c # mA.h を読み込む | +---- A.c # mA.h と A.h を読み込む | +----inc/ | +
Makefile で現在処理中の makefile のパスを知りたい（未解決） #2 - satosystemsの日記
まず、適当な名前でシェルスクリプトを用意する。 #!/bin/bash while getopts C:f: OPT do case $OPT in "C" ) ;; "f" ) filename="$OPTARG";; esac done if [ "$file" != "" ]; then export CURRENT_MAKEFILE=$filename fi make $@ シェルスクリプトの起動引数を処理するのは getopts が簡単だ。 そして適当な名前で Makefile を用意する（ここでは commons.mk とする）。 MAKE=make_wrapper.shこれは、make の代わりに呼び出されるシェルスクリプトを MAKE マクロに再定義している。 そして、環境変数 MAKEFILES を定義する。 export MAKEFILES=commons.mk 環境変
CentOS on EeeBOX/mjpeg-streamerでストリーミング配信 - snagplaces on @wiki
#right{最終更新日時：&update(j) [&link_edit(text=編集)]} *はじめに mjpg-streamerは、UVCカメラに対応したストリーミング配信ができます。 静止画のほか、Motion-Jpeg、Java、JavaScript、VideoLANの配信に対応しているので、ストリーミングの基本を見るには最適なパッケージだと思います。 **注意事項 -libjpeg-develがインストール済み（libjpegだけではダメ） -音声は出ません。音声も欲しい場合はffmpeg等による配信を検討してください。 #contents ---- *mjpg-streamerのダウンロードとコンパイル mjpg-streamerのダウンロード（svnなので常に最新版です） # svn co https://mjpg-streamer.svn.sourceforge.net/
GNU make 日本語訳(Coop編) - ルールの記述
makefileに現れるルールは、いつ、どうやって特定のファイル——これをターゲットといい、ほとんどはルールひとつにつき１つだけです——を作り直すかを指示します。ルールはターゲットの依存関係である別のファイルや、ターゲットを作成したり更新したりするためのコマンドを列挙します。 ルールの順番に意味はありません。ただし、makeにターゲットを与えるためにあるデフォルトゴールを他の方法で指定しなかった場合を除きます。デフォルトゴールとは一番初めのmakefileの最初のルールのターゲットのことです。最初のルールに複数のターゲットがある場合、一番初めのターゲットだけをデフォルトとみなします。 ただしこれには、ピリオド(".")で始まるターゲットは、一つ以上のスラッシュ("/")のようなものを含んでいない限りはデフォルトにはならない、それから型ルールを定義するターゲットはデフォルトゴールとして機能し
でっつ :: Entries :: お母さんみたいにもっと３ヶ月前に教えて欲しい
お母さんみたいにもっと３ヶ月前に教えて欲しい Posted by admin on the 28th of 3 月, 2008 at 12:00 am under 未分類. This post has no comments. ccacheを使えば、C++のコードのコンパイルが死ぬほど遅くても大丈夫という情報が。これはheaderファイルなど頻繁には変更しないような部分のコンパイル結果を自動的にキャッシュしてくれるソフトウエアだ。よっぽどのことがないかぎり、一人で開発しているコードでは、includeする色々なheaderファイルのほうが、自分で入力するソースコードより多い。しかも、template programmingを使いまくるBoost Spiritのようなinculdeするheaderが大きくて、構文解析の処理量が多いライブラリを利用していると、明らかにheaderのせいで
OMake つかったらC言語でプログラム書く手間がバカみたいに減った - 日記を書く[・ _ゝ・]はやみずさん
OMakeすごい。OMakeはマジですごい。 OMakeはGNU makeの代替品みたいなものなんだけど、正直なところこのツールの強力さはGNU makeと比べると失礼なくらいすごい。これのおかげで、「コード修正→ビルド→デバッグ→コード修正→・・・」のループの、ビルドにあたる作業がほぼ消え去った。 ファイルの依存関係の解析がとにかくすごい。よくあるユースケースなんかの場合、最小限の手間でほぼ完璧に依存関係を網羅して、よしなにビルドしてくれる。 とりあえず、はやみずが実際に使ってみたケースを例にとってそのすごさの一端を紹介しようと思う。 case study 論より証拠ということで、自分が OMake を試しにつかってみたケースを紹介する。C言語でスタティックライブラリを作っていて、それに加えて簡単なテストプログラムを書いている。 /include/ 以下にヘッダファイルが全部ある /sr
![OMake つかったらC言語でプログラム書く手間がバカみたいに減った - 日記を書く[・ _ゝ・]はやみずさん](https://cdn-ak-scissors.b.st-hatena.com/image/square/04e015dad70084a57fdfa9a2686c0c93441c5d2d/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127128184977%2F17680117127128193858%2F1557447212)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
