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

[Fergus Henderson]

On 16-Mar-1998, Peter Schachte <pets at students.cs.mu.oz.au> wrote:
> 
> 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.

I think the reduction in pollution is a good idea, but everything-in-
one-subdirectory is probably not (except for backwards compatibility).

So, as an alternative to the original proposal,
how about

	Mercury/ints/foo.int
	Mercury/ints/bar.int
	Mercury/cs/foo.c
	Mercury/cs/bar.c
	Mercury/os/foo.o
	Mercury/os/bar.o

or

	Mercury/foo.dir/foo.int
	Mercury/foo.dir/foo.c
	Mercury/foo.dir/foo.o
	Mercury/bar.dir/bar.int
	Mercury/bar.dir/bar.c
	Mercury/bar.dir/bar.o

(depending on which way you want to slice them)?

> Orthogonally to this
> question, it might be best to leave .o files in the parent directory,
> more like a C or other language compiler.

Maybe...

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

Names beginning with "." are usually more trouble than they are worth.

If there's only one subdirectory name, then the directory pollution
should be acceptable.  It seems to be acceptable for `CVS' and `RCS',
for example.

> Personally, I'd probably want all of these.

Hmm... if you want all of those different things, it's starting to
get a bit complex -- how about generalizing it?

We could have a `--file-names <pattern-list>' option
or alternatively a MERCURY_FILE_NAMES environment variable,
where <pattern-list> is a sequence of `<ext>=<pattern>' strings
separated by spaces, <ext> is one of the standard file extensions
(`.o', `.int', etc.) or `*', and <pattern> is a relative path name
which may contain the following format specifiers:
	%m	The module name (using `.' as module qualfier)
	%M	The module name (using the directory separator,
		i.e. `/' or `\', as module qualifier)
	%e	The extension (without the `.')

For example, the current convention is

	mmc --file-names "*=%m.%e"

and the two alternatives conventions given above would be specified as

	mmc --file-names "*=Mercury/%es/%m.%e"
	mmc --file-names "*=Mercury/%m.dir/%m.%e"

If you want `.o' files in the current directory, then just
add ".o=%m.o" at the start, e.g.

	mmc --file-names ".o=%m.o *=Mercury/%es/%m.%e"

On the other hand, supporting something like this could encourage
a proliferation of different naming conventions, which would be a
bad thing.

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

Generally not.

> If not, does it really make that much difference

I don't know.  I want to implement both ways of slicing so that
we can test it out.

I hope not.  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.

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