Date: Thu, 20 Jun 1996 16:16:49 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) 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 Subject: Re: tcl -- what's going on here. Message-ID: <199606202316.QAA16672@phaeton.artisoft.com> In-Reply-To: <199606200347.NAA05052@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jun 20, 96 01:17:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606202316.QAA16672>