Date: Wed, 19 Jun 1996 15:29:20 -0400 From: Garrett Wollman <wollman@lcs.mit.edu> To: "Jonathan M. Bresler" <jmb@freefall.freebsd.org> Cc: current@FreeBSD.org Subject: Re: tcl -- what's going on here. Message-ID: <9606191929.AA16806@halloran-eldar.lcs.mit.edu> In-Reply-To: <199606191719.KAA01800@freefall.freebsd.org> References: <199606191656.KAA06240@rocky.sri.MT.net> <199606191719.KAA01800@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 19 Jun 1996 10:19:40 -0700 (PDT), "Jonathan M. Bresler" <jmb@freefall.freebsd.org> said: > from what jordan wrote, it seems that bmak'ing these programs is > an arduous task that no one is eager to take on. at least some of > those that have been doing it are tiring of the process. That is certainly what is being suggested, but I must confess to not understanding it. Writing a Makefile for a large program or set of programs is a pain, yes. It is substantially less of a pain when using the Berkeley macros. In any case, it is something that only has to be done /once/. I think there is a bit of cognitive dissonance going on here. I think what PHK and others complain about is the effort required to take the vendor's tree and merge it into the FreeBSD arrangement. 99.9999% of this effort is completely unnecessary, and results from either an incorrect initial import of the code (e.g., gcc), or completely unnecessary and counterproductive local changes (e.g., trailing whitespace removal). In particular, there is ABSOLUTELY NO NEED to move large numbers of files around; indeed, this is quite counterproductive, as we have seen. See the sources to mrouted(8) for the correct way to handle a distribution that does not come set up one-program-per-directory. In all the programs I maintain, including a particularly large one (xntpd), the actual effort involved in converting them to use the Berkeley macros is already sunk, and does not need to be repeated. The process of importing new revisions takes a few hours' worth of time, mostly involved in examining the merge conflicts for important local changes. It is by no means an arduous process as some people seem to be making it out to be. > using gmake for them would reduce the burden of porting these > programs. For most programs, it doesn't matter which `make' executable one uses. The difference is between using the Berkeley macro set and not using it, and the compromises this entails. > i dont understand how using gmake for GNU programs is more evil > than using gcc for all of FreeBSD. if the build tool "contaminates" > the resulting binary...all of FreeBSD is in that boat. Again, the executable for the `make' program is of little relevance. I venture to say that GNU `make' could be taught to use a BSD-style macro system in short order (although a significant amount of effort). The win we get from using Berkeley make macros is as follows: 1) All the standard targets do standard things. 2) The obj directory hack works, and works better than some of the `replacement' mechanisms that have been suggested. 3) The Makefiles are simple enough for a janitor to understand. 4) The configuration variables that we have set up work precisely as intended. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@lcs.mit.edu | Shashish is the bonding of hearts in spite of distance. Opinions not those of| It is a bond more powerful than absence. We like people MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9606191929.AA16806>