Date: Wed, 19 Jun 1996 18:29:40 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: 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: <199606200129.SAA14683@phaeton.artisoft.com> In-Reply-To: <199606200128.KAA04284@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jun 20, 96 10:58:58 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. My instinctual response to this is "YES!". My intellectual response to this is "Where things get installed is part of the build structure". My considered response is "everything that isn't applicable to building the code on FreeBSD is cruft resulting from failure to limit interfaces the code uses to those defined by standards like POSIX". > 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 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". > 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". The real problem with upgrading Flex is the existing components and packages which depend on historical behaviour. Nate is right that it doesn't need to be upgraded, unless you happen to be working on something third-party. From the point of view of the source tree, the upgrade only needs to happen if someone is importing flex-using components into the source tree, or refreshing ports. This is precisely my reasoning for *not* supporting the importation of additional scripting languages into the main line distribution; /bin/sh has screwed us badly enough without needing to allow people to add to the problem out of ignorance (or even malice). > 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. The Makefiles are the smallest part, IMO, of upgrading FLEX. Basically, you must rebuild everything -- all system components, and all ports and packages -- to be assured that you haven't screwed anyone. > > 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. Agreed. The gmake is a GPL dependency that should be eliminated. But when packages need gmake, you are implicitly approving bmaking those particular packages. I don't think you can reconcile this position with that of not "bmake'ing" FLEX (or other packages). 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?199606200129.SAA14683>