> Greg Earle wrote:
>>> It seems it doesn't do quite what you want, well, I agree with you that it
>>> would be nice to have what you want.  But I'm not prepared to call DESTDIR
>>> useless because of that.
>> 
>> I didn't say it was useless, but it's currently an agonizingly-close-to-100%
>> (call it 98%) solution.  If <curses.h> properly got installed in the
>> beginning stages, and there were a way to build the -current gcc2 from the
>> existing 1.1 gcc 2.4.5 without it gagging on libgcc2.c, it would be at
>> least 99 44/100ths %.  Then one could build into $DESTDIR, see everything
>> built correctly, and then either try some chroot'ed tests (as Phil Knaack
>> mentioned) or risk it all and boot from floppy, mount the disk(s) and tar up
>> $DESTDIR on top of the existing system.  If I have install a small part of
>> the -current system - especially something as vital as the *compiler* - to
>> get everything to go, then I see little point in trying to use DESTDIR.  If
>> I have to blow away something important, might as well blow it all away, eh?
> 
> Hmmm...
> 
> Can you install the new gcc into $DESTDIR/bin, and then put that at the top
> of your path for the next stage of compilation?

I hadn't thought of that.  That might work ... set $DESTDIR, do the steps
that Jason Thorpe mentioned, then reset $PATH and re-try "make build" from
/usr/src.

> Similarly, do a make install in src/include into $DESTDIR/include, and then
> put this include dir at the front of the options in a -I option?

You don't need to do this.  If $DESTDIR is set, the Makefiles already know the
right magic to use not only -I${DESTDIR/include/[...] et al., but also to use
the "-nostdinc" and "-idirafter" switches to ignore /usr/include and only to
use -I${DESTDIR/include/[...] and other explicitly-named include directories.
Another reason I really liked DESTDIR; I was delighted to see all this stuff
happen automagically when I set $DESTDIR.

	- Greg