Date: Fri, 23 Aug 1996 06:30:50 -0500 From: rkw@dataplex.net (Richard Wackerbarth) To: Julian Assange <proff@suburbia.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Am I wrong or is this just stupid?r Message-ID: <v02140b01ae43419986b9@[199.183.109.242]>
next in thread | raw e-mail | index | archive | help
>> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02140b01ae43419986b9>