[m-dev.] putting all those little files in subdirectories

[Peter Schachte]

On Fri, 13 Mar 1998, Fergus Henderson wrote:

> Zoltan and I spent some time discussing how to solve the problems
> caused by having a zillion files all in the one huge directory.

Great news!

> The big question is which way to slice them.
> If we have modules `foo', `bar', `baz', etc., and
> file extensions `.c', `o', `.int', etc., then
> should the subdirectories be named `foo.dir', `bar.dir', etc.,
> or should they be named `cs', `os', `ints', etc.?

I'd like to suggest three other things to consider.  Firstly, as an
alternative to the two "slicings" you mention above, it might be best
to put all the generated files into one subdirectory.  This cuts even
further the pollution of the user's directory with mercury-generated
files he doesn't want to be bothered with.  Orthogonally to this
question, it might be best to leave .o files in the parent directory,
more like a C or other language compiler.  Finally, and orthogonally
to either of these issues, some users might prefer if you began
subdirectory names with a ".".  Again, an issue of directory
pollution.  Personally, I'd probably want all of these.

> There are advantages to both ways.  If you have lots of
> different modules, then the `foo.dir' etc. approach is likely
> to be faster for Mmake, but the other approach is faster and
> more convenient for things like `rm -rf os', `mv os os.$GRADE.$ARCH', etc.

Why?  Doesn't unix hash directories for fast exact filename lookup?
If not, does it really make that much difference (other than through
DEC's horrible NFS implementation)?  It'd be interesting to know how
much difference the choice of slicings among the two you suggested,
plus the all-in-one-subdirectory approach plus the no-subdirectory
(status quo) approach makes to Mmake times.


-Peter Schachte			| He who asks is a fool for five minutes, but
pets at cs.mu.OZ.AU		| he who does not ask remains a fool forever.
http://www.cs.mu.oz.au/~pets/	| -- Old Chinese saying 
PGP key available on request	|