From owner-freebsd-hackers Tue Aug 27 04:09:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA29707 for hackers-outgoing; Tue, 27 Aug 1996 04:09:10 -0700 (PDT) Received: from skiddaw.elsevier.co.uk (root@skiddaw.elsevier.co.uk [193.131.222.60]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA29698 for ; Tue, 27 Aug 1996 04:09:07 -0700 (PDT) Received: from snowdon.elsevier.co.uk (snowdon.elsevier.co.uk [193.131.197.164]) by skiddaw.elsevier.co.uk (8.6.13/8.6.12) with ESMTP id MAA03691 for ; Tue, 27 Aug 1996 12:08:49 +0100 Received: from tees.elsevier.co.uk (actually host tees) by snowdon with SMTP (PP); Tue, 27 Aug 1996 12:08:24 +0100 Received: (from dpr@localhost) by tees.elsevier.co.uk (8.6.13/8.6.12) id MAA03205; Tue, 27 Aug 1996 12:07:23 +0100 To: rkw@shark.dataplex.net (Richard Wackerbarth) Cc: Julian Elischer , hackers@FreeBSD.org Subject: Re: Am I wrong or is this just stupid?r References: From: Paul Richards Date: 27 Aug 1996 12:07:22 +0100 In-Reply-To: rkw@dataplex.net's message of Fri, 23 Aug 1996 19:19:19 -0500 Message-ID: <57u3tpjdat.fsf@elsevier.co.uk> Lines: 59 X-Mailer: Gnus v5.3/Emacs 19.30 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk rkw@dataplex.net (Richard Wackerbarth) writes: > Julian Elischer writes: > > This is the common method of using "cookies" to represent a portion of the > build process. > > We would probably want to have 3 conditions. > 1) Unconditionally build the tools > 2) Test to see if the tools are up-to-date > 3) Assume the tools are up-to-date as of the time of the cookie. > > This can be done with two tokens, "tools_built" and "tools_changed". This is all ridiculously complex for a relatively rare occurence these days. An upgrade of the tools does *NOT* imply that a bootstrap stage is required. We're talking about different problems here. I think an explanation of the historical reasons for the current setup is required for those who weren't around. In the very early days things were very broken, the compiler had bugs, the libraries had bugs, the headers had bugs all the build tools had bugs. We were fixing critical parts of the build system very frequently and we needed a way to ensure that all the build components were fixed before rebuilding the entire system. After running into problems where people weren't seeing bugs fixed because they weren't rebuilding the tools properly we came up with the world target which systematically rebuilds all the essential build tools in an order that ensures that the final make all target is run with a working build environment. Now, times have changed. Critical bug fixes to the build environment are *rare*. Most of the time they are tweaks or enhancements and building with the old tools doesn't create hidden bugs as a side effect of the build process. Therefore, you don't need to bootstrap all the build tools since the currently installed tools work fine. All the extra baggage that we currently have is probably unecessary, though it's comforting to know that a make world should always work. Since the build environment is stable a "make all" is enough to upgrade your system safely and this will remain to be so as long as no new bugs are introduced into the build tools. Now, this *will* happen, say when we try out gcc 2.7.x and there also also occasions when a new tool, such as lint, will not build without some glue. These individual cases can all be added on an ad-hoc basis to the bootstrap target during a release cycle and then removed at the beginning of the next development cycle since at that point you should be at the same working baseline again. I added the bootstrap target some time ago so I think I pass the "contributed a solution" requirement :-) -- Paul Richards. Originative Solutions Ltd. (Netcraft Ltd. contractor) Elsevier Science TIS online journal project. Email: p.richards@elsevier.co.uk Phone: 0370 462071 (Mobile), +44 (0)1865 843155