Date: 27 Aug 1996 12:07:22 +0100 From: Paul Richards <p.richards@elsevier.co.uk> To: rkw@shark.dataplex.net (Richard Wackerbarth) Cc: Julian Elischer <julian@whistle.com>, hackers@FreeBSD.org Subject: Re: Am I wrong or is this just stupid?r Message-ID: <57u3tpjdat.fsf@elsevier.co.uk> In-Reply-To: rkw@dataplex.net's message of Fri, 23 Aug 1996 19:19:19 -0500 References: <v02140b04ae43d488b422@[199.183.109.242]>
next in thread | previous in thread | raw e-mail | index | archive | help
rkw@dataplex.net (Richard Wackerbarth) writes: > Julian Elischer <julian@whistle.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57u3tpjdat.fsf>