From owner-freebsd-current Fri Jan 21 21: 6:30 2000 Delivered-To: freebsd-current@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id D63CD15728 for ; Fri, 21 Jan 2000 21:06:22 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (qmail 31513 invoked from network); 22 Jan 2000 05:02:13 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 22 Jan 2000 05:02:13 -0000 Date: Sat, 22 Jan 2000 16:02:10 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Jason Evans Cc: David O'Brien , current@FreeBSD.ORG Subject: Re: even more breakage in current In-Reply-To: <20000121162540.E27689@sturm.canonware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message