はてなブックマーク

久しぶりにCMakeの話。 外部の依存ライブラリがあるC/C++のコードをCMakeでビルドする場合、インクルードパスやライブラリパスを指定する必要がある。パスを直接指定する方法以前書いた。しかし、そこで書いたのはパスやライブラリ名を直接指定するもので、それらがすでに分かっている必要がある。 しかし、システムにインストールされたライブラリを使うような場合はそのパスを探し出して指定する必要がある。システムによってインストールされた場所が異なることがあるためだ。Unix系OSでよく使われるGNU Autotools環境では、ライブラリの探索はAutoconfの役目で、`./configure && make`の`./configure`スクリプトが行う。では同様のことをCMakeでやるにはどうすれば良いだろうか。 ということで今回はCMakeのライブラリ探索の話。方法はいくつかあるので、順番に

Emacsには便利なelispパッケージがあるが、最近ではpackage.elというのが付属していて、ネットワーク上からパッケージをインストール仕組みができている。以前はウェブ上から手作業でダウンロードして.emacs.dに下に保存していたが、package.elを使えば一覧から好きなものを選択するだけでインストールできる。 ということで、package.elの設定と自動インストールの設定をしてみた。 基本設定 デフォルトではelpa.gnu.orgから取得するようになっているが、ここにあるパッケージはあまり多くない。MELPA（Milkypostman’s Emacs Lisp Package Archive）というところに多く集まっているので、これを追加しよう。 MELPAを使う設定は公式サイトにあるが、Emacs-24なら以下で良い。 (require 'package) (add-

C/C++のメモリリークチェックツールと言えばvalgrindが有名だが、メッセージの詳細を日本語で説明しているサイトはあまりないようなので調べてみた。 valgrindは、mallocやnewで確保されたメモリ領域がポインタによって辿れるかどうかをチェックすることでメモリリークを検出する。以下の例を見てみよう。 char *g_ptr; void func(){ char *p = new char[32]; // (A) } int main(){ func(); } main関数から始まり、そこからfuncが呼ばれ、現在 (A) の位置にいるとしよう。このとき、メモリ上にはmain関数とfunc関数で定義された変数があり、また、グローバル変数であるg_ptrも有効な状態で存在している。func関数が抜けると変数pは無効になる。 このpやg_ptrのようなデータのことをroot-set

Ubuntu標準のインターフェースであるUnityだが、デフォルト状態では正直あまり使いやすくないし、見た目もイマイチだと思う。 MateやKDEを入れるという手もあるが、なんとかUnityを使ってやろうと思い、色々設定してみた。 設定ツールのインストール システム設定から設定できる項目は少なく、痒いところに手が届かない。CompizConfig Settings ManagerとUnity Tweak Toolを入れよう。 $ sudo apt-get install compizconfig-settings-manager unity-tweak-toolUnityの設定は「システム設定」、「Unity Tweak Tool」、「Compiz Config Settings Manager」の3つを使うことになる。一部の項目はどれを使っても可能だったりするが、どれも守備範囲が異なるの

最近Webアプリを作ることがあって、動作チェックのためにcurlコマンドを色々使った。オプションが色々あって、データ送信の方法に分かりにくいのところもあったので、使い方をまとめてみる。 なぜ分かりにくいか 理由1: 送信方法が色々ある 単にデータ送信と言っても、やり方がいくつかある。Webアプリに対してデータを送る方法は大きく4つあると思う。それぞれの場合に応じたオプションを使わなければ成らない。また、そもそも作られたサービスがどの形式を期待しているかを知っていなければならない。 URLエンコードによるPOST マルチパートによるPOST REST APIでのPOST クエリ文字列 理由2: データの渡し方も色々ある 送るデータを指定する方法もいくつかあり、やはりオプションを使い分けなければならない。 データをコマンド中で指定する データを含むをファイルを指定する name=content

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

Linuxで共有ライブラリ（*.so）を作るようになったのでちょっと勉強してみた。今までは使うだけだったので、以下のようなことは知っていた。 作るときはgccの-sharedオプションを使う。 使うときはgccの"-lライブラリ名"でリンクするライブラリを指定する。 リンク時のライブラリ探索パスは-Lオプションで指定する。 実行時のライブラリ探索パスは/etc/ld.so.confに書いてあるディレクトリ。環境変数LD_LIBRARY_PATHでも指定可能。 ライブラリを作るときは、.cから.oを作るときに-fPICをつけるといいらしい。 新しくライブラリを入れたときはldconfigするといいらしい。 逆に今まであまり知らなかったこと。 ほとんどのライブラリはlibhoge.so, libhoge.so.1, libhoge.so.1.1のように3つくらいのファイルがあり、libhoge

最近LLVMについて調べてみたのでまとめてみる。自分はコンパイラの専門家でも何でもないので間違った内容があるかもしれない。 GCCとコンパイラの仕組み LLVMの前にまずはコンパイラ一般の話。コンパイラはまずソースコードを解析して内部表現にする。これはたいていツリー構造となる。このツリー構造のデータに対して文法チェックを行ったり最適化処理を行ったりした後に、オブジェクトファイルを生成する。 コンパイラの内部表現だが、実際には複数の種類の内部表現を使っていることが多いらしく、GCCもそのようになっている（[1]の図3）。これによるとまずはその言語固有のツリーにするようだ（C trees, C++ treesなど）。これをGENERICという形式にする。GENERICは名前のとおり言語に依存しない一般的な形式で、どの言語の場合も一度GENERICにする。 GENERICはその後さらにGIMPL

はじめに CMakeを調べた経緯 CやC++でプログラムを書くときは普通何らかのビルドツールを使う。Unix/LinuxならMakeが多いだろう。Makefileにビルド手順を書くわけだ。一方WindowsでVisual Studio（以下VS）を使うときはVS上でビルドの設定を行い、その結果はプロジェクトファイル（.vcproj）に保存される。 そのため、Unix/LinuxとWindows両方に対応しようとすると、例えばソースファイルを追加するたびにMakefileとVSのプロジェクトファイルの両方を修正することになる。さらにEclipse CDTでも開発できるようにしようと考えたり、あるいは古いVS用のプロジェクトファイルが必要になったりすると、サポートするビルド環境がどんどん増えていく。 当然管理も面倒になり普段使わないものが段々放置され、ついにはビルドできなくなる。そしてそのこと