Date: Thu, 20 Jun 1996 10:58:58 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: jmb@freefall.freebsd.org (Jonathan M. Bresler) Cc: jkh@time.cdrom.com, nate@sri.MT.net, phk@freebsd.org, current@freebsd.org Subject: Re: tcl -- what's going on here. Message-ID: <199606200128.KAA04284@genesis.atrad.adelaide.edu.au> In-Reply-To: <199606191653.JAA29372@freefall.freebsd.org> from "Jonathan M. Bresler" at Jun 19, 96 09:53:40 am
next in thread | previous in thread | raw e-mail | index | archive | help
Jonathan M. Bresler stands accused of saying: > > bmake'ing tcl, gcc, groff, etc...every time a new version comes > out is a real pain. so is having a monster like this in the > cvs tree. So far so good. Personally I find the concept of going back to a vendor (whther it be Ousterhout or Stallman) and saying 'your product doesn't work under FreeBSD. Here are some patches, and oh by the way we totally mutilated your source to make it fit our particular pet build process so you'll have to pick the real changes from the chaff.' particularly ridiculous. If the current build scheme can't handle third-party build structures in some sensible fashion, then it is _BROKEN_ from the point of view of the useful continuation of the expansion of FreeBSD. Garret, Paul et al., this was discussed last time the import of gcc 2.7.2 was raised. I can only assume that you decided the issue was beneath yourselves and killed the thread. The conclusion that was reached last time was that a framework which maintained the original build structure would be highly desirable from the point of view of working more closely with vendors. Nate's comments about Flex are telling. His insistence that he hasn't upgraded it "because it wasn't necessary" aren't borne out by the continuing questions being asked along the lines of "the Flex in /usr/bin is version a.b.c which is really old and has lots of bugs and can't be used to compile XYZ, you need version i.j.k instead". I'm not accusing Nate of being lazy; I'm suggesting that upgrading Flex would be a lot easier if it weren't necessary to start by rewriting the makefile from scratch. > bmake'ing gmake and having gmake a prerequisite for these other > GNU components is ugly (two make programs: gmake and bmake) but > avoids both problems. I am totally opposed to having gmake in the tree. Note particularly that neither gcc nor tcl require it, and in fact I suspect that most of the basic FSF tools don't either. > i imagine that there are other cvs issues here that escape me > but what of incorporating gmake and using it in place of bmake > for GNU stuff. and not bringing in these monster tarballs. Huh? this makes no sense whatsoever. The issue is not about which make is used, it's about the structure of the Makefile(s) and source trees involved. > Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606200128.KAA04284>