From owner-freebsd-hackers Fri Aug 23 04:32:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA12671 for hackers-outgoing; Fri, 23 Aug 1996 04:32:03 -0700 (PDT) Received: from eel.dataplex.net (EEL.DATAPLEX.NET [199.183.109.245]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA12655 for ; Fri, 23 Aug 1996 04:31:59 -0700 (PDT) Received: from [199.183.109.242] (cod [199.183.109.242]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id GAA24711; Fri, 23 Aug 1996 06:30:45 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Aug 1996 06:30:50 -0500 To: Julian Assange From: rkw@dataplex.net (Richard Wackerbarth) Subject: Re: Am I wrong or is this just stupid?r Cc: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Looking more at our make world methodology, I'm wondering at >> stuff like this: >> >> # lib-tools - build tools to compile and install the libraries. >> # >> lib-tools: >> cd ${.CURDIR}/usr.bin/tsort && \ >> ${MAKE} ${MK_FLAGS} all install ${CLEANDIR} ${OBJDIR} >> ... ^^^^^^^^^^^ >> >> I know that one can turn this off by whacking CLEANDIR, but why even >> do this at all for the intermediate build targets? We build the >> miscellaneous build tools, the compiler tools and all the core >> libraries only to throw away the results of all that work so that we >> can come around and do it all over again when it comes time to make it >> all from the top. I've looked at all the ordering issues with this >> and I still can't see the logic of it. Anyone in opposition to simply >> >> Jordan > >Keeping in mind that install is before ${CLEANDIR}, I believe the idea >is to remake the tools _with_the_new_tools_ before using them to remake >other things. i.e if you upgraded to gcc2.7.2 then first make gcc2.7.2 >with your old gcc, then remake it with the new one. I agree that this was the logic behind the process. However, how often do we really upgrade gcc, etc. ? IMHO, the problem occurs because of the "build in place" mentality as opposed to the idea of "moving down the block". If we would adopt the idea that everything is made in a context which, in general, is NOT that of the running system, we can get a number of benefits. 1) We would be able to build for a new release on a stable production system. 2) We stand a chance of getting to cross platform builds. 3) We can use "make" to decide just what really needs to be recompiled. The arbitrary multiple recompilations would no longer be necessary. In the special, but common, case of bootstrapping yourself from one version of -current to the next, use of links to share common elements would allow the virtual contexts to exist without wasting a lot of disk space.