[ On Wednesday, May 7, 2003 at 22:42:55 (-0400), Andrew Brown wrote: ]
> Subject: Re: why not "make includes" before "make do-tools" for build.sh?
>
> > In the situation I'm talking about you have to go back and manually run
> > "make includes", or start from scratch, anyway, and either way the same
> > results should be created.  The normal dependencies recorded by the
> > dependall step should take care of recompiling any objects which make
> > use of the updated header file(s).  Indeed in my example that's exactly
> > what ended up happening.
> 
> okay, suppose that for some reason, printf(3) gets versioned.  that
> means stdio.h would change.  you cvs update (or whatever), and then
> run build.sh.  doing make includes before building your tools means
> that stdio.h gets updated.  then you try to build your tools.  they
> all use the new stdio.h that references the new printf(3) prototype.
> 
> but since you don't have the libc that goes with the header, you can't
> link anything.
> 
> or did i misunderstand your original idea?

You may have missed/ignored the fact that I'm building on the netbsd-1-6
branch where such ABI changes are not normally allowed!  :-)

You also seem to have forgot that there's a critically important
document, UPDATING, which people tracking the trunk must read if they
expect to have above average success in their builds.  It will, or at
least is supposed to, tell people when changes have been made that will
cause "build -u" to fail.

In this case I had done a full build.  I then changed the header file
and the other uses of the affected macro in the source tree and tried
another full build which failed because I had made a typo in my change
to the header file.  So I fixed the header in the source tree and tried
a "build -u".  That should have worked, and it did work after I manually
forced a "make includes" run.

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