白井です。 > > 面倒なとおっしゃいますが、よく考えられた綺麗なツリーだと思いますよ > > 。私の場合、あのツリーのまま CVS に入れています。ですから、 > > install.rb を放り込めばそれだけで配布パッケージが完成してしまいます > > 。例えば： > うーむ、本当にそのままなんですね……。それは考えてませんでした。 他にも rubycocoa, ruby-dbi, shim 、これらは少なくとも"そのまま"の形で CVS に入っています。思うに install.rb/setup.rb って配布用のインストーラ に留まらず、優れたビルドシステムともいえるんじゃないかと思います。 > あのツリーは直接使うにはちょっとツリーが深すぎるような気がするん > ですよ。あと言ったとおり、小さいツールとかをパラパラとその場に > 置けないのが嫌です。CVS/ もありますし。 私の場合も結構小さなツールを置いていますが、 tarball にする際にはその 都度 CVS のリポジトリからチェックアウトしますから、 cvs add しない限り余 計なものが混じる危険性はありません。 CVS/ については tarball にする際に find -name CVS|xargs rm -rf してしまいます。（作業用のツリーとは全く別だ から、「破壊的」な操作が可能です） > > 今のところ、このツリー以外の形で開発用のソースツリーを持つ理由は考え > > られません。青木さんの場合は、開発用と配布用とでは全く別のツリーで管 > > 理しているのでしょうか？ > > はい。ぼくのはこんな感じです。 > > ~/r/ > ... > 配布用には remake というコマンドを使ってゼロから再配置してます。 > 次のようなファイルを作っておいて remake pack と打つと全部やって > くれるようになってます。(でも pack の定義はここにはない。 > environ('rubyprog/tmail') の時点で rubyprog から継承している) > ... つまり、どのファイルがどんな役割を持っているか（ bin,lib,ext ）という のは外側で定義しているわけですよね。で、 remake によって振り分けられたそ れらをインストールするために install.rb/setup.rb が存在すると。これだと 、ファイルにアクセスする際に役割の階層を気にせず、素早くアクセスできると いう利点があります。 とはいっても、 bin,lib,ext という階層分けが煩わしいかというと、そうも 言えないと思います。よほど面倒臭ければ $ ln -s bin/* lib/LIBNAME/* . という風にリンクを上手に使う手もありますしね。それよりも、チェックアウト したソースツリーに install.rb/setup.rb が直接適用できることの利点が大き いんじゃないかと思います。これは、誰かが Anonymous CVS からソースを取っ て来て、ビルドしたいというケースを考えると非常に分かりやすい仕組みです。 ですから、 > しかしそれならそもそも現在の setup.rb の「ディレクトリツリー (のみ) > で属性を指定する」という前提が崩れるので、ディレクトリツリー縛りは単 > なる負担になってしまいます。それだったら全部作り直したほうが楽です。 負担というよりも、むしろこうした構造に従うことで良いソース管理ができると 思うのです。 > 本気で考えれば、無視すべきファイルパターンは固定しないでしょう。たと > えば *.in は入れてほしくないとか、いくらでも変則的な要求は考えられま > す。だからちゃんと問題を解決するには、たぶんその逆にインストールすべ > きファイルを指定するべきです。 もっとも、色々と変則的なケースが想定されます。でも、 RCS CVS *~ *.bak *.BAK core *.core #* .#* *.orig *.rej *.old は多分ほとんどの人が除いて欲しいと思っているパターンのファイルだと思うし （ rsync にも --cvs-exclude というオプションがあるくらいです）、これらを インストール処理の対象から除いても誰も困らないのではないかな、と。ほんの 一部の人達（私とるびきちさん）が幸せになれる為にパッチを取り込んで欲しい と思ったりするんですけど、だめ？ -- shirai / korinkan.co.jp Shirai,Kaoru Korinkan Ltd.