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 12:23:49
In article <> you write:
>[ On Wednesday, May 7, 2003 at 23:12:07 (+0100), Ben Harris wrote: ]
>> Subject: Re: why not "make includes" before "make do-tools" for
>> In article <> you write:
>> > Why not do "make includes" before "make do-tools" for
>> In the general case, because "make includes" needs ${INSTALL}, which is
>> built by "make do-tools".
>Hmmm...  I knew there must be something!  :-)
>However, how about just building nbinstall right after building nbmake,
>right from with a similar script?

That would work (except that you have to build ${HOST_MKDEP} as well).

>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.

>> > It's necessary if you are trying to get buy with using " -u"
>> > _and_ if changes to headers are needed in order to successfully build
>> > some tools,
>> NetBSD _should_ be able to compile on earlier versions of itself (at least
>> back to the latest formal release), so unless your host system is
>> comprehensively screwed, this situation should never arise.  I don't think
>> that requiring some effort to recover a screwed host system is unreasonable.
>It must have been further along than I thought (it's so hard to tell
>with all the very long command lines!  ;-), probably into building libc.

grepping your build log for '===>' is a good way to work out what's going

>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.

Ben Harris                                                   <>
Portmaster, NetBSD/acorn26           <URL:>