In article <m19Docu-000B3kC@proven.weird.com> you write:
>[ On Thursday, May 8, 2003 at 12:23:49 (+0100), Ben Harris wrote: ]
>> Subject: Re: why not "make includes" before "make do-tools" for build.sh?
>>
>> In article <m19DXWr-000B3kC@proven.weird.com> you write:
>> > Also, it seems to me that ${INSTALL} doesn't really have to be nbinstall
>> > either, since strictly not even -g and u are needed, and not even really
>> > '-m', and so something like the GNU Autoconf install.sh script would do
>> > fine for those few platforms without a usable native 'install'.  Heck
>> > I think even "cp" would suffice for installing the tools, wouldn't it?
>> 
>> Erm, we wanted it for "make includes", and then we _do_ need all the funky
>> features of nbinstall, since the include files need to be owned by root or
>> included in the METALOG as appropriate.
>
>The tools in $TOOLDIR can and should be owned by the builder.

Yes, but you were suggesting that nbinstall wasn't needed for "make
includes", for which it _is_ necessary to get stuff right.  "make includes"
doesn't install into $TOOLDIR, it installs into $DESTDIR.

>> > I had added a local custom entry to <paths.h>, but spelled it wrong.  I
>> > fixed it and re-started with "./build.sh -u ..." but the updated
>> > <paths.h> didn't get copied into $DESTDIR and it failed again in the
>> > same spot.
>> 
>> So your host system was screwed.  I think that given the infinity of ways
>> you can screw your host system, the build system can't really be expected to
>> work around all of them.
>
>The host system didn't include the custom changed header file.

Hrm.  In that case something was more seriously wrong.  Building the tools
shouldn't look at the headers in $DESTDIR at all.  It uses some headers from
the source tree, but they should be used in-place.  After all, on a fresh
build, $DESTDIR is empty when the tools get built.

I'd like to try to reproduce your problem, but my only convenient big build
box runs Linux, and I don't think the 1.6 branch will build on a Linux
host.  I can try it with -current if you give me a recipe, but I suspect
enough has changed that it'll behave differently.

>(and just to repeat what was obvious from my initial post but what may
>have been lost since by the abbreviation of my example commands:  I am
>NOT using "-D /", and indeed I am doing unprivileged builds as I would
>never think to do anything else :-)

Ah, OK.  I'd somehow missed that, not least because if you're doing that,
the kind of mistake you made really shouldn't screw things up that badly,
even without your suggested change.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/acorn26           <URL:http://www.netbsd.org/Ports/acorn26/>