On Thu, 09 Aug 2007, Jeremy C. Reed wrote:
> > Where did it rebuild nbmake "for no reason"?  (You didn't post the
> > relevant output.)  Why aren't you passing a "-T" option to build.sh,
> > which is the documented way of preventing unnecessary builds of nbmake?
> > Do you have build.sh revision 1.168 or later, which tries to be more
> > clever even if you don't pass a "-T" option.
> 
> This conflicts with:
> 
> On Thu, 9 Aug 2007, Thor Lancelot Simon wrote:
> 
> > nbmake is *always* rebuilt no matter what's done with the rest of
> > the toolchain.

Thor was mistaken; The make wrapper script is always rebuilt, but nbmake
itself is not rebuilt if (a) build.sh knows or can guess where the
TOOLDIR is, and (b) ${TOOLDIR}/bin/nbmake is newer than any of the
sources in src/usr.bin/make.

> It was not rebuilt once I did:
> 
>  ln -s obj/tooldir.NetBSD-3.99.24-i386 \
>          /opt/src/obj/tooldir.NetBSD-3.99.24-i386
> 
> (as mentioned in first email)

In that case, everything was working as designed.  Since you didn't
explicitly specify a TOOLDIR, you get a default TOOLDIR that depends on
the kernel version; since the kernel version changed, the new TOOLDIR
didn't exist, so ${TOOLDIR}/bin/nbmake certainly didn't exist.

> That was my point. I now understand that build.sh tries to be more
> clever, but since it is recommended to boot with new kernel before
> doing the installation, it is not clever enough.

How do you suggest that build.sh could figure out the location of a
TOOLDIR that was used in some previous build.sh invocation with some
other kernel version, if you don't specify it via the "-T" flag?

--apb (Alan Barrett)