putting all those little files in subdirectories

[Fergus Henderson]

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

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.?
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.

The good news is that we can with relative ease implement both ways of
slicing, and also allow no slicing at all (as happens currently --
allowing this is important because any changes will break people's
existing Mmakefiles).  This can be done fairly elegantly by simply
having all uses of file names go through a single predicate which takes
a module name and a file extension, and based on the current option
settings returns either `foo.dir/foo.o' or `os/foo.o' or plain `foo.o'. 
All the code that creates filenames already goes through a predicate
module_name_to_file_name, so much of the work is already one.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.