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

[Zoltan Somogyi]

> > The slicing on extension approach seems much nicer
> > than the slicing on module name approach, so if it it doesn't
> > make much difference, then we go with just the former.
> 
> That would be simpler.  Though if it doesn't make much difference, why not
> put them all in one Mercury subdirectory? 

Because that *would* make a difference, by multiplying the maximum directory
size by a large factor.

Actually, even adding an extra pathname component (Mercury/) on a thousand
files will slow down make significantly. We can accept this slowdown if
it yields a bigger speedup by reducing the impact of n^2 directory search
algorithms in the kernel, but I wouldn't want to pay it just to get
a very slightly cleaner directory name space.

Another consideration that the name space redesign should address is
the ability for object files for more than one architecture to coexist.
This is especially important if cyclone is down, or if a bug shows up
only on an architecture which is not your main development platform
(e.g. SPARC register windows). Both situations have come up recently.
I don't think you need more directories for this; including the platform
name in the object file name (and if necessary, the C file name)
would be enough.

Along the same lines, being able to have both traced and non-traced C and
object files around at the same time will soon be desirable.

Zoltan.