last update: 2013/09/03

2005/07/08

消えゆく運命

所詮はコーダーか。

ちょうど1ヶ月ぐらい前のことでしょうか。なんかいろいろありまして、研究室でわりとハブられ気味なわけです。

まぁその理由っていうのがわりとというかかなり些細なことだったんですが、私が研究室で書いてるプログラムが利用してるベースライブラリが1学年上のメンバーの手で書かれてるのは何回かここでも触れたのでおぼえてる人もいるかと思うんですが、それのソースのディレクトリわけがsource、headerって感じでcppとhppを分けるようになっていたわけです。

Makefile書いたりする人はわりとわかるかと思いますが、cppとhppを分けてディレクトリに配置してるっていうのは非常に非効率なわけです。たとえば、私はWindows、Linux、MacOSの3つのOSでビルドする関係上、バイナリが混ざらないように中間オブジェクトなどの出力ファイルを各OS用のディレクトリに振り分けるわけですが、Makefileでcppとかのファイル名のリストのマクロに全部ディレクトリ名がついてるので、g++ -cで中間オブジェクトを出力する先を指定する際に面倒なことになったりするわけです。具体的に言えば、macってディレクトリ内に.oを出そうとすると、source/Class.cppみたいなのが列挙された$(CPP-FILES)マクロから$(CPP-OBJS)を作っているので、macディレクトリ内にさらにsourceって掘っちゃって美しくないわけです。

他にも、依存ライブラリとかのシステムヘッダではない、単にcppのための定義をおいたhppが別ディレクトリにあるとgrepとかかけてなんかを探すときも隣りディレクトリを走査しなきゃなんないし(これが子ディレクトリなら再帰的にディレクトリをめぐるという手もありますがcppとhppが同じディレクトリにあればそんな必要もない)、実際そういうディレクトリわけをしてるソースを今までに見たことがなかったので既存ツールとの親和性について非効率と思われる点とともにそれを指摘したことがありました。

余談ですが、私はフラットに置くのを好みますが、GNUあたりはプロジェクトディレクトリの下にsrc, libなどに分けておくみたいですね。まぁsrcディレクトリの中はヘッダとソースが一緒にあるのでこの点では問題はありませんし、わたしもsrcディレクトリを作るのが問題だと言っているわけではありません。あくまでも、ヘッダとソースが別れてる点をここでは問題にしていました。

で、どうもそれが癪に障ったらしく 個人にケンカを売りたいなら買っても良いですが、あまりに攻撃方法が幼稚なんじゃないの? なんてことをいわれてしまいまして、もちろん私はそんなことを意図して言ったわけではありませんが、さすがに目上とはいえ目に余る言いようだったので 攻撃と受け取るのが幼稚なんじゃないか的な話もありますが。 なんてことを言いつつ、メンテナはそっちなので必要以上に干渉をするつもりもない、と言ってみたりしたところ、それ以来ぷっつりその人は2週間ほど研究室に現れなくなりました。まぁ2週間経ったら何事もなかったかのように来ましたが。

…とまぁそんなことがありまして、結局研究室内での力関係でいえば博士行きを決めてる向こうの方が上ですし、私が院卒業した年のさらに2年後まで研究室に残る人なので、向こうの研究に対するビジョンの方がより長い目で見つめていることは確か。

で、「所詮はコーダーか。」と冒頭で書いた理由なんですが、その例のベースライブラリをインタフェースを変えてさらにもう1回書き直すことにしたようで、今までのpublicなインタフェースも一応obsoleteながら残すが、そのうちサポートされなくなるとのこと。

そもそもそのベースライブラリは過去5,6年ぐらい引っ張ってきたPureCで書かれたすごいスパゲッティなんだけど超人的なポリシーで書かれてる(Cとコールバック関数を駆使してC++同様のオブジェクト指向を実現していて、しかもSTLのサブセットになるコンテナのテンプレートをプリプロセッサマクロで実装しているとかいうすごいやつ)ライブラリが、さすがにメンテナンスできないぞということで、C++でささっと書かれたものでした。

で、それなりに完成度も上がってきて、今年の3月の東京での発表でもその新しい方のベースライブラリ+私がそれ用に書いたミドルライブラリでもって発表してきた経緯があったわけですが、そこまでのレベルまで来てるヤツが今回APIを変えて1から書き直しと。となれば、こっちのミドルライブラリも書き直し必至なわけです(もとい必死です)。

まぁそれだけなら別にいいんですが(さすがに「パフォーマンス向上」のためにAPIを根本的に変えるのはどうかと思いますが)、そのほかにさらにいうと今使ってるGLUTフレームワークをやめてSDLを使おうかという話を練ったりしてるみたいです。まぁ私のミドルライブラリレベルではGLUTは使ってないGL+GLUな環境なので(ついでに言えばMVCアーキテクチャになっとるのでViewだけDirectXとかに差し替えるのも可能)、下からの移植性が無くなる上に上への移植性も…とはまだなってませんが、そもそもSDL使おうかと言ってるわりにSDLを使ったサンプルを1個も出してきてない段階でそう易々とフレームワークを変えていいもんなんですかねーと、不信感たっぷりです。まぁ陰ではこっそりできてるのかもしれませんが、それが私の目に触れてこない時点で不信感たっぷりですし、そういう可能性も含めてハブられてるともそりゃ感じますね。というかSDLに関する話がミドルライブラリ作ってるこっちに全くこないので。

私がよくいう言葉に「論よりコード」って言葉があります(まぁ「論より行動」とかいう時もありますが)。結局の所机上でぶちあげた新計画も結構ですが、それができることを実際に示せるようなコードを書いてからそういうのはぶちあげるべきなんじゃないかと思うんですよね。実際に動いてるコードがあって周りから見ても「うん、こういう感じならいけそうだ」みたいな感じになってこそ周囲の協力が得られるもんなんだと思ってます。

実際にここ2ヶ月、研究室の同期と「あれやったら面白そうだよねー」みたいな話をいくつかしてみたときに、すぐ翌日に実装にとりかかってプレビューしてみせたりもしてますし、さすがに私はできる見通しが立ってないようなことを軽々しく口走るようなことはできなかったときのリスクを考えるとできません。

とまぁそんなわけで、今回のベースライブラリの完全リライト、そしてフレームワークの変更と、なんともいやな感じです。いや、本当にできるかどうかという点もありますが、結局のとこ彼から見れば私は所詮コーダー、私の書いてるミドルライブラリも私の卒業後は引き継ぐ人間がいなくなり消えゆく運命なのかもしれませんし、そういう方向性にもっていくためという思惑として私の目には映っている事はたしか。

そんなことなら別に今がんばって研究したって、今がんばってコーディングしたって生きてこない研究/コーディングなら別に気合い入れてやる意味もねぇなーと。そう考えるとあんまり研究室でどっぷりコード書いてる意味も感じられないしねぇー。なんてことをこの頃考えているわけです。

まぁでも昨日の話じゃないですが別に引きこもるような気もないので研究室にはちゃんと顔出して適当になんかコード書いたりはしてるでしょうが、なんとも張り合いのない気分ですね。ここまでの話はすべて私の一方的な視点で書いてるので大体主観ですが、別に事実をねじ曲げて書いてるようなことも特にないような気もするなー。まぁどうしようもないけど、やる気はそがれる出来事ばっかりってことです、はい。どろどろしてていやですね。

あーちなみに、そのベースライブラリを作りなおすに当たって結果的に一時しのぎという形になったそのライブラリの悪かった点を本人が挙げていたのですが、そのひとつとして 研究室の中心的存在になろうとするうざい人間が現れた (強調 by kawazoel)というのがありました。まぁこれが本音なんでしょうね。ここまで書かれちゃ私もお手上げです。

comments powered by Disqus