Whining Express

<< 2011-07-14 >>

最近いつになく C を書いている。WZ マクロ以来かもしれないくらい。いつか Python に帰ってくるぞ、と。

で、C は、コードの中味以外で気を遣うことが多すぎる、と思った。ライブラリ使うにも、コンパイルに一苦労したり、コンパイル通ってもリンクでこけたり。リンクできても実行時にこけたり。英語のドキュメントを必死で調べたり検索しまくったりしないといけない。

それに、そうしてようやく手に入れたバイナリのライブラリを自分のプロジェクトにどうやって配置したものか迷う。オトナはみんな通ってきた道なんでしょうけど……。

たとえば CUnit 使うとして、バイナリは（あとヘッダファイルは）リポジトリに格納すべき？　もちろん自分のコードじゃないから、格納しても基本的に編集するわけじゃない。しかし数年後に同じライブラリが同様に手に入るかというと絶対の保証はないわけで。リポジトリにそういう外部のライブラリも格納しておけば、チェックアウトするだけで、依存しているライブラリを求めてサイト回ってコンパイルする苦労を何度もしなくても、即ビルドできる。

ところがそういうバイナリは、それだけぽんとリポジトリに入っていてもそのうち素性がわからなくなる（はず）。じゃあ元のソースコードもリポジトリに入れときますか、ということになるとさらにプロジェクトの容量が肥大化する。CUnit くらいならそんなに大きくないからいいけど、wxWidgets くらいまで行ったらどうすんの？　それにそういう外部のライブラリ使うプロジェクトが複数あったら？　（実際あるけど。）各プロジェクトにそれぞれリンクするバイナリを入れとくの？

で、思いついて svn:externals とか駆使してみたりしたんだけど、これを入れると svn up が遅くなる！　外部リンクひとつごとに、たとえ同じリポジトリからでも別個にセッション張るそうで、やたら時間がかかって調子が狂う。ちゃんと動いていることは動いているんだけど、作業効率のこと考えると svn:externals はあんまりよくないね……。

このへんのノウハウは『Subversion 実践入門』という本を参考にしてるのだけど、実際にどこまで踏み込むかはプロジェクトごとにそれぞれなんだろうな。というわけでまだ模索中。

昔はそれぞれのコンピュータに CUnit なり wx なりインストールしとけばいいじゃない、とおおらかに思ってたけど、できれば隔離したいのよね。依存関係が曖昧になりそうで。それはちゃんと書いとけばいいのか。で、バイナリはどこかに保存しておく？　そのままじゃコンパイル通らなくて、たとえば Makefile いじったりしたのはどう記録しとく？　動的リンクで DLL が必要になったら？

なんかちゃんとやろうとするとどんどん深みにはまっていく気がする。そんな話。