Date: Wed, 7 Aug 1996 11:27:53 -0600 (MDT) From: Nate Williams <nate@mt.sri.com> To: Poul-Henning Kamp <phk@critter.tfs.com> Cc: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com>, peter@spinner.dialix.com (Peter Wemm), nate@mt.sri.com, current@freebsd.org Subject: Re: Whither gcc 2.7? Message-ID: <199608071727.LAA01936@rocky.mt.sri.com> In-Reply-To: <7094.839436646@critter.tfs.com> References: <199608071601.JAA05628@GndRsh.aac.dev.com> <7094.839436646@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Poul-Henning Kamp writes: > In message <199608071601.JAA05628@GndRsh.aac.dev.com>, "Rodney W. Grimes" write > s: > >Remeber, what goes into src/contrib should be the _complete_ sources, with > >_no_ changes at all, otherwise we might as well go back to what we have > >been doing. > > no. I disagree here. It is legal and required to remove stuff that > qualifies as "bloat". I agree with both of you, although I will state that the reason the 'ports' tree doesn't work as well as the current 'Bmake' paradigm is because of the above problem. By using a subset of the tree, you are still requiring that the importer 'hack' the sources to fit into our tree, otherwise the size involved becomes so great as to make it necessary to unbundle the compiler. And, you have to 'build' the converted Makefile, which is at least as difficult as doing the BMake makefile. The arguements put forth about 'not sending changes' back are specious. If it was important to send the FreeBSD changes back to the FSF they could be done 'trivially'. Almost all of the changes merged in after an import are FreeBSD specific, since we don't import the Makefiles as part of the import. Also, the FSF tend to re-organize their directory structures on major releases, which will cause a huge amount of grief in the CVS repository and lots of work for the importer, so I still don't see a benefit. I still fail to see the advantage of building things in /src/contrib, but I've given up arguing since it does not good. *None* of the reasons brought up against the current Bmake setup were in any way valid, but since we've got a big hammer all the world looks like a nail. 'Ports is successful, so everything should be in the ports paradigm that isn't supplied by CSRG'. *sigh* In any case, if we bring in gcc, bringing in the *entire* distribution would be a big mistake IMHO. The usefulness of other parts is minimal at best, and the cost is spectacularly large in terms of disk space. Heck, the entire gcc 2.7.2 distribution is bigger than bin, include, libexec, sbin, and usr.bin combined. :( > The gcc support for any cpu but i386 qualifies for that. If we move over to the new setup, we should be careful not to make the same mistakes we did before and ship sources that we can generate (yacc/lex) instead of generating them. This was a problem in the last version that I should have fixed in my subsequent updates, but I was too lazy. :( The only subdir tree larger than *just* the gcc 2.7 sources is the GNU tree, which includes gcc 2.6.3. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608071727.LAA01936>