>> >Why not do "make includes" before "make do-tools" for build.sh?
>> >
>> >It's necessary if you are trying to get buy with using "build.sh -u"
>> >_and_ if changes to headers are needed in order to successfully build
>> >some tools, but I'm not sure if it's possible (i.e. whether or not all
>> >the tools used by "make includes" are already built and installed in the
>> >tools directory before the general "make do-tools").  It seems to work
>> >OK, but that's only after getting half-way through the do-tools stage
>> >and then deciding to try saving some time with '-u'....
>> 
>> that strikes me as a bad idea, since you could then end up with
>> include files that reference functions that aren't implemented in libc
>> yet, for example: __unsetenv13, __sigaction14, ...
>
>How do you think that could possibly ever happen?!?!?
>
>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?

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."