[ 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:
> > 
> > However, how about just building nbinstall right after building nbmake,
> > right from build.sh with a similar buildnbinstall.sh script?
> 
> That would work (except that you have to build ${HOST_MKDEP} as well).

Ah, yes...  agreed.

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

METALOG is, as far as I can tell, never needed for the installation of
the tools.

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

If I'd have kept one....  :-(

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

The build system really should be expected to work properly with this
kind of change since it wasn't using the host system's headers but
rather the headers installed in $DESTDIR/include.

Remember that regardless of what change I actually made and which module
encountered an error because of it, the overall affect was that
"./build.sh -u" didn't work, and it didn't work because the fixed header
was not re-installed during the "./build.sh -u" run.  What did work was
manually re-doing the "includes" step.

(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 :-)

I've since made the following change and have redone a full build and
several update builds with no problem, at least not for a netbsd hosted
build (where the native install and mkdep commands are sufficient for
building and installing the toools into TOOLDIR).

$ cvs diff Makefile                                                
Index: Makefile
===================================================================
RCS file: /cvs/master/m-NetBSD/main/src/Makefile,v
retrieving revision 1.175.2.3
diff -c -r1.175.2.3 Makefile
*** Makefile    30 Nov 2002 15:27:33 -0000      1.175.2.3
--- Makefile    7 May 2003 17:52:31 -0000
***************
*** 130,143 ****
  .if ${MKOBJDIRS} != "no"
  BUILDTARGETS+=        obj
  .endif
  .if ${USETOOLS} == "yes"
  BUILDTARGETS+=        do-tools
  .endif
  .if !defined(NODISTRIBDIRS)
  BUILDTARGETS+=        do-distrib-dirs
- .endif
- .if !defined(NOINCLUDES)
- BUILDTARGETS+=        includes
  .endif
  BUILDTARGETS+=        do-lib-csu do-lib-libc do-lib do-gnu-lib do-build
  
--- 130,143 ----
  .if ${MKOBJDIRS} != "no"
  BUILDTARGETS+=        obj
  .endif
+ .if !defined(NOINCLUDES)
+ BUILDTARGETS+=        includes
+ .endif
  .if ${USETOOLS} == "yes"
  BUILDTARGETS+=        do-tools
  .endif
  .if !defined(NODISTRIBDIRS)
  BUILDTARGETS+=        do-distrib-dirs
  .endif
  BUILDTARGETS+=        do-lib-csu do-lib-libc do-lib do-gnu-lib do-build
  


-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>