[replies sent directly to me may timeout and bounce, since I'm not
 online as often as I should be, but I'll check the list archives]


> >In this case, the user is manually deleting the objdir tree (including the
> >top-level directory).
> 
> of course.  like me.  :)

Actually, that was only one example I gave of a situation where I'd want
the build process to (re)create its playground.

Another possibility, and one which I'm presently using elsewhere when
building multiple objdir trees, is using a shell expression to create
a relatively unique playground, so that for each build, I get a new
and separate object tree, if, say, I want to revert to last week's
built source or look into the build from a few days ago or whatever.

Say that I want to create /usr/obj/NetBSD-20020223 for today's build.
And then build a week later, keeping today's build, and last week's,
and so on.  Or say /usr/obj/NetBSD-1.5.2 soon-to-be-automagically
NetBSD-1.5.3 .

Yeah, it leaves cruft around that even in these days of 160GB disposable
hard disks, eventually I'll want to clean up.  But if I were to want
to do this in spite of being ...um, unusual, I'd still need to figure
out the date, create the directory, start the build, with my luck just a
second past midnight so it fails again.


I think that what is best is if I simply check out the source each
time and let `cvs' merge in my hacks to create the wanted object dir
if needed for each build, and run with my own mutant makefile, rather
than try to get it officially adopted.  But I wanted to toss out the
idea and get reactions to it to get a feel for the waters.


thanks,
barry bouwsma