Satoru Takabayashi
sator****@namaz*****
2004年 1月 22日 (木) 01:02:09 JST
shiro****@lava*****: > > Gauche にも Makefile.PL に相当する枠組みがあると便利だと思う > > のですが、そういった計画はありますでしょうか。 > > これに関しては、ちょっと慎重になっています。 > > 以前、STkとPerlを半々で使っていた時に、Makefile.PLに触発されて > 似たような仕組み(Makefile.stk)を作って使っていました。 なるほど。すでに経験済だったのですね。 > - Common caseに関してはとても簡単になる。しかし、それを外れた > ことをしようとすると大変。 > -- 提供されるメカニズムの裏に回ってハックする→結局、表面のAPI > ではなく内部を全て知る必要があり、抽象化されないし、変更にも弱い。 あ、これは似たようなことを自分も automake で経験しました。 (結局、不自由よりメリットの方が大きかったので automake の流 儀に適応してしまいましたが) > Makefile.PL的アプローチのもうひとつの利点は、メインの処理系が > バージョンアップしてビルドプロセスが変わった場合に、拡張モジュールの > ソースに手を加えること無く変更を反映できることです。その点に関しては、 > Gaucheでは早い段階から標準的なconfigure.in, Makefile.inの > テンプレートを用意することと、autoconfマクロを用意することで対応しました。 すみません。これ、知りませんでした。examples/spigot がテンプ レートだったのですね。 > Gaucheの拡張モジュールに関しては、既にGaucheがインストールされている > ことが前提とできるので、もうすこし補助的なスクリプトを増やしても > 良いかと考えています。例えば賢いinstallとか。 > 標準的なテンプレートを最初に作ってくれるスクリプトも > あってもいいかもしれませんが、各拡張モジュールに関して最初に > 一度だけしか必要でない作業ですので、あまり重要ではないと考えています。 examples/spigot の configure.in と Makefile.in が使われてい れば問題ないと思いますが、個々のライブラリのビルドとインストー ル方法がまちまちだとユーザは苦労するので、その辺は統一される ように働きかけていくのがいいかなと思います。 Ruby の場合、各種のライブラリのインストール方法がまちまちで、 中には $HOME の下に簡単に入らないものがあったりして苦労する ときがときどきあるので…。 p.s. make にあわせると魔窟になるので scheme 版 ant みたいなのを作っ たらどうすか、と Debian の鵜飼さんは言ってました。
