Shiro Kawai
shiro****@lava*****
2004年 1月 21日 (水) 00:20:34 JST
From: Satoru Takabayashi <sator****@namaz*****> Subject: [Gauche-devel-jp] Makefile.scm? Date: Tue, 20 Jan 2004 23:20:02 +0900 > Gauche にも Makefile.PL に相当する枠組みがあると便利だと思う > のですが、そういった計画はありますでしょうか。 これに関しては、ちょっと慎重になっています。 以前、STkとPerlを半々で使っていた時に、Makefile.PLに触発されて 似たような仕組み(Makefile.stk)を作って使っていました。 そこで得られた経験は： - Common caseに関してはとても簡単になる。しかし、それを外れた ことをしようとすると大変。 -- 提供されるメカニズムの裏に回ってハックする→結局、表面のAPI ではなく内部を全て知る必要があり、抽象化されないし、変更にも弱い。 -- そういう例外をサポートするAPIをメカニズムに追加する→どんどん APIが肥大化する。 - その機構の中だけで生きられるならハッピーだが、そういう機構を 複数組み合わせなければならない場合 (例：単一パッケージで、 STkとPerlの両方のライブラリを生成するようなもの)、開発者も メンテナも両方を理解する必要が出てくる。バッドノウハウの塊に なりがち。 この経験から、Gaucheではビルドとインストールメカニズムについては 「なるべく事実上の標準となっているものを使う」という方針に しました。具体的には: - autoconf - gmake (ほんとはこの縛りはなくしたいが、全てのmakeに対応しようと すると却って大変) - 上記のメカニズムのみでは繁雑になる場合に、そこから呼ばれる 小さなシェルスクリプトかGaucheスクリプトを作る。 Makefile.PLのように独自フレームワークから既存のツールをキックする のではなく、フレームワークは既存のものを利用し、そこから呼ばれる 部分に関して必要ならば独自部品を使う、という方向です。このほうが 方針の違うビルドプロセスを組み合わせて使う場合に使いまわしがきく と考えています。 Makefile.PL的アプローチのもうひとつの利点は、メインの処理系が バージョンアップしてビルドプロセスが変わった場合に、拡張モジュールの ソースに手を加えること無く変更を反映できることです。その点に関しては、 Gaucheでは早い段階から標準的なconfigure.in, Makefile.inの テンプレートを用意することと、autoconfマクロを用意することで対応しました。 Gaucheの拡張モジュールに関しては、既にGaucheがインストールされている ことが前提とできるので、もうすこし補助的なスクリプトを増やしても 良いかと考えています。例えば賢いinstallとか。 標準的なテンプレートを最初に作ってくれるスクリプトも あってもいいかもしれませんが、各拡張モジュールに関して最初に 一度だけしか必要でない作業ですので、あまり重要ではないと考えています。 なお、以下の機構に関してはおそらく今後も採用しません： - Makefile.inの自動生成 - automake - libtool --shiro
