Date: Thu, 20 Jun 1996 13:17:46 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: terry@lambert.org (Terry Lambert) Cc: msmith@atrad.adelaide.edu.au, jmb@freefall.freebsd.org, jkh@time.cdrom.com, nate@sri.MT.net, phk@freebsd.org, current@freebsd.org Subject: Re: tcl -- what's going on here. Message-ID: <199606200347.NAA05052@genesis.atrad.adelaide.edu.au> In-Reply-To: <199606200129.SAA14683@phaeton.artisoft.com> from "Terry Lambert" at Jun 19, 96 06:29:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert stands accused of saying: > > 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. > > I don't remember this; was this not on -current or -hackers where this > was discussed? I'm fairly sure it was on one of the above; my reading list is probably a small subset of yours so I'm surprised you don't recall it. It's also not inconcievable that I'm hallucinating and that I was in fact participating in a conversation with a couple of fluffy blue cushions. > I like the idea of vendor-branching, but, for instance, the ability > to build cross environments or alternate processor architectures is > not handled well by the GNU "Configure" crap, which wants to "localize" > source to the target environment. This is simply something that the > GNU folks "do badly". It's hard to agree to not replacing code that > I believe is "done badly". It's lots easier to decide that you shouldn't have done it when the next version comes along and you have to merge their changes with yours. I'm entirely in favour of the current bmake functionality, and the integration that we currently have is an enormous and wonderful thing, and I quite understand the resistance to any thought of throwing it away. However; if a third-party supplied product is to be included with a minimum of fuss, _particularly_ an excessively hairy one like GCC, it would be _desirable_ to have a means of mapping its own build functionality to that required by the current FreeBSD structure. > The real problem with upgrading Flex is the existing components and > packages which depend on historical behaviour. Nate is right that Flex was a convenient example because I'd been fielding questions on it since before the beginning of the year. As Nate has observed, it wasn't necessarily a lot of work, so it was probably not as good an example as it could have been. > Terry Lambert -- ]] 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?199606200347.NAA05052>