From owner-freebsd-current Thu Jun 20 16:21:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA25256 for current-outgoing; Thu, 20 Jun 1996 16:21:14 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA25249; Thu, 20 Jun 1996 16:21:11 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA16672; Thu, 20 Jun 1996 16:16:49 -0700 From: Terry Lambert Message-Id: <199606202316.QAA16672@phaeton.artisoft.com> Subject: Re: tcl -- what's going on here. To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Thu, 20 Jun 1996 16:16:49 -0700 (MST) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, jmb@freefall.freebsd.org, jkh@time.cdrom.com, nate@sri.MT.net, phk@freebsd.org, current@freebsd.org In-Reply-To: <199606200347.NAA05052@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jun 20, 96 01:17:46 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 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. 8-). > > 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. This is only an issue if the vendor goes through serious code reorganization between releases. This generally does not happen for an evolutionary product. You handle this by shadowing the build tree and making from the vendor tree. You apply branch deltas, as necessary, to localise, and you pass back, in their build tree layout format, the changes necessary for your platform, for inclusion in the next release. > 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. GCC has some recognizably broken behavior in its use of localization instead of conditional compilation. The need for localization persists precisely because they have not dealt with the issues by resolving them instead of adding localization data. Actually, I agree with you for most conditionally-compiled packages, it's just that the FLEX example was invalid, and anything that goes through GNU configure is kind of bogus for any cross-platform shared (aka "Read Only") source trees. The error with that, I guess, is that the packages that are being conditionally-compiled... don't cause the type of problem that this is tying to solve. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.