JUENGST> I think it is a good question to ask why make install doesn't
JUENGST> create required target directories. I think it should.

Not long ago, the <bsd.foo.mk> templates and many makefiles had
"install -d ..." commands to create target directories.

It's not too surprising that the Makefiles and the mtree files were
incomplete, and occasionally conflicted with each other.  Even if
someone managed to reconcile the differences, I think it's an
impossible task to keep everything in sync.

Since maintaining consistant directory names, location, permissions,
ownerships, etc. is a whole lot easier with three mtree files compared
with a zillion makefiles, it was decided that the mtree files would be
the one way to specify target directories.


Your point that systems upgraded without mtree have files installed
incorrectly is valid.  The requirement to use mtree to create target
directories is neither documented nor obvious.  

I also think that adding install -d's back to the Makefiles is a step
backwards.  Can a call to mtree can be added to src/Makefile's install
target be done safely?  I routinely do a "make distrib-dirs" before
installing with no ill effects.  If it is safe, I see no reason not 
to add it to the top level makefile.


JUENGST> In my opinion it's a bad idea to use mtree configuration
JUENGST> files to create required directories, especially if these
JUENGST> mtree configuration files don't exist.  Chris, do you realy
JUENGST> think that people like to use BSD make if they have to handle
JUENGST> additional mtree configuration files? I don't think so.  The
JUENGST> MIT X11 imake does create the required subdirectories and
JUENGST> that's fine.

But the mtree config files do exist, they are correct, and are
convienent to use and administer.

Please remember that the BSD build environment is tailored for the
needs of building of an entire operating system.  Make and mtree are
two of the tools that allow us to accomplish those tasks.  The needs
of BSD and X11 are different.

JUENGST> Last, but not least I sent you (Chris) patches which do
JUENGST> remove the special rules in the Makefiles of ar, crontab,
JUENGST> disklabel and ranlib, which are required to build the
JUENGST> additional manual pages files (these programs do have two man
JUENGST> files).

Yes.  The special case make rules are gross, but IMO using new
subdirectories is even worse.  There has to be a better way.


JUENGST> for i in 1 5
JUENGST> do
JUENGST>   (rm -rf man$i ; mkdir man$i ; cd man$i ;\
JUENGST>    ln -s ../../../libexec/cron/crontab.$i crontab.$i )
JUENGST> done
JUENGST> #why are these manual pages in src/libexec/cron ?

You'll note that _every_ crontab file is in src/libexec/cron.  That is
because I use cvs to import new versions when Paul Vixie releases them
yet still be able to maintain NetBSD-specific enhancements.

For example, Vixie uses curly braces in the crontab manpage to
indicate optional command line arguments instead of the more common
square brackets.  I sent him a patch that "fixed" them, anlong with
some others that made crontab POSIX.2 compliant.  He integrated the
POSIX changes, but ommited the curly brace fix.  No matter how much I
complain via email; or if I post to usenet; or hold my breath; he's
unlikely to integrate my patch.  He's the maintainer, and I have to
live with his decisions.

But I have the source, and can fix it so NetBSD's crontab manpage uses
square brackets.  In the same manner, there are some things that you
may feel that should be integrated into NetBSD that the Core group
decides not to.  You're lucky, You have source, and can change it to
your liking.

	--jtc




------------------------------------------------------------------------------