なんだBoost.Iostreamsってbzip2とzlibのためのjamfile用意してるじゃん．中読んだらソースを直で引っ張ってくる方法も書いてあったので，ためしにソースだけ引っ張ってきてBoostのビルドの際に "-sBZIP2_SOURCE=なんちゃら" と "-sZLIB_SOURCE=なんちゃら" とだけ指定したらよろしくやってくれるし．bzip2の方はtar玉なソースしかなくて解凍レンジでチンしてみると案の定改行がLF（そのくせ.defなんかはCRLF）だったけれど，少なくともMSVCはソースファイル毎でCRLF/LFごちゃまぜでもよろしくやってくれたはずなので（゜ε゜）キニシナイ! っていうかビルド通ったから大丈夫．うん．多分…大丈夫…かな？
ユーザ側の環境に特定のライブラリの要求を行うときに「このライブラリ使いますんでそれのソースだけ用意しててください．ビルド周りはこちらがよろしくやりますから．ライセンスのcompatibility他細かいことはそっちでてけとーに注意してください．んじゃノシ」っつーのは，特に個人的にプラットフォーム非依存なモノ作ろうとするときには（少なくともビルドする側にとっては）楽な方法だなー．C++の場合は特にABIなどの観点からtool chain（とtoolの設定）を統一しないといけないという意味でも重要だし．
こーゆー状況ではビルドツールのportabilityが重要な意味を持ってくるんだろうけれど，Boost.Buildがもうちょっと普及してきてくれればなー．少なくともこんふぃぎゃー（名古屋弁風味）&負けファイルはお世辞にもportableとは言えない…．
＃そもそもmakeって他のプロジェクトからターゲットレベルで何かを引っ張ってくるような使い方ができたっけ？＜実はmakeを良く知らない人
ICUのビルドみたくこっちの環境では負けファイルであっちの環境ではIDEのバッチビルドで，とやると結局バッドノウハウの蓄積になるわけで…．もちろん，プラットフォーム非依存で何かやろうとすると結局ある程度のバッドノウハウは必要にはなるんだけれど，そこはなるべくツールに吸収していただきたいわけで．もちろん，autoconf/automakeよりはるかに抽象度の高いレベルでのプラットフォーム差異吸収．
