Subject: Re: why not "make includes" before "make do-tools" for
To: None <tech-userlevel@NetBSD.ORG>
From: Ben Harris <>
List: tech-userlevel
Date: 05/08/2003 23:07:42
In article <> 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
>> In article <> 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 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 "./ -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                                                   <>
Portmaster, NetBSD/acorn26           <URL:>