[ruby-list:37085] Re: setup.rb: Patch to ignore CVS,*~,...

　白井です。

> > 　面倒なとおっしゃいますが、よく考えられた綺麗なツリーだと思いますよ
> > 。私の場合、あのツリーのまま 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 というオプションがあるくらいです）、これらを
インストール処理の対象から除いても誰も困らないのではないかな、と。ほんの
一部の人達（私とるびきちさん）が幸せになれる為にパッチを取り込んで欲しい
と思ったりするんですけど、だめ？

-- 
[e-mail]

Shirai,Kaoru
  Korinkan Ltd.