On Fri, 21 Jan 2000, Jason Evans wrote:
> I often do a 'make includes' to be able to iteratively test changes. Once
> I'm happy that the changes are sound, there is no way to assure that the
> changes didn't cause a bootstrapping problem like this one.
`make includes' breaks your test environment. The problem is harder for
developers. Developers have to install new headers to test them (except
for system header in the SHARED=symlinks case, which is very convenient
for development but is almost equivalent to an automatic `make includes'
since most header changes are in system headers). I don't see any better
ways to test header changes before committing them than to keep a
separate tree which is almost current, apply the changes to that tree,
and do a `NOCLEAN=1 make buildworld' on it. I rarely do this :-).
> This is the second time that this has been a problem for me. The first
> time I caught it and put a hack in the libc_r Makefile:
>
> CFLAGS+=-I${.CURDIR}/../../include
>
> Marcel said that this is not appropriate for reasons I didn't understand.
> If this isn't appropriate, and the build system is structured such that it
> pulls definitions from the installed headers, then what *is* the correct
> solution?
The build system installs the necessary headers at the necessary times.
The above gets in its way by doing the equivalent of installing headers
before they are ready to be used. I think it currently doesn't actually
cause in problems in libc_r/Makefile, because libc_r doesn't have any
tools that need to be built with the old includes.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
