From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1efdd369be089610 X-Google-Attributes: gid103376,public X-Google-Thread: 1025b4,1d8ab55e71d08f3d X-Google-Attributes: gid1025b4,public From: kenner@lab.ultra.nyu.edu (Richard Kenner) Subject: Re: what DOES the GPL really say? Date: 1997/09/05 Message-ID: <5uoso1$cj5$1@news.nyu.edu>#1/1 X-Deja-AN: 270008152 References: <5u93bu$5cj$1@news.nyu.edu> Organization: New York University Ultracomputer Research Lab Newsgroups: comp.lang.ada,gnu.misc.discuss Date: 1997-09-05T00:00:00+00:00 List-Id: In article Ronald Cole writes: >I thought the main thrust was to get a g++ out to the public that had >working templates... No, certainly not! EGCS is not meant to directly produce anything for "the public", but to debug/improve experimental changes and pass them into the GCC development stream. I don't follow g++ development, so I don't understand the reference to "working templates", but the same folks who set up egcs have total control over the g++ part of the released GCC, so they don't need to set up any separate project to get anything "to the public". >Even so, the egcs faq says that the egcs project >will "result in a more useful compiler, a more stable compiler, a >central compiler that works for more people, a compiler that generates >better code." Better than what? Better than what's available now. The idea is that having such a framework will allow the time to adequately debug/improve complex changes that can't fit into the normally rapid pace of the FSF's GCC development. This is a very worthwhile goal. For example, if it had been in place two years ago, the exception handling changes would have been debugging in that framework, rather than holding up the mainline GCC release and lots of other useful things. We'd now be at GCC 2.10 or so instead of just coming up on 2.8. That's why I strongly support this project. The basic idea is that if a proposed change is in good enough shape that it can be gotten ready in, at most, a month or two, it goes directly into the GCC development tree and will appear in the next release within a few months. If the change need more testing or other work, it gets shunted over to egcs for that work. When it's ready, it can go into the development GCC. This process will allow these changes, which previously were hard to handle, to be handled without upsetting the normally rapid pace of GCC development and will allow for a much better compiler in a couple of years. >Have you actually read the egcs home pages, Richard? No, but I have heard there are some thing that were hastily written and that may be what's confusing you. Also, if you're thinking about the recent past, you may thing of the GCC development effort as producing a low rate of releases. Quite the opposite is true historically and I think you'll better understand the role of egcs in that context. > A compiler is a complicated piece of software, there will still be > strong central maintainers who will reject patches, who will demand > documentation of implementations, and who will keep the level of > quality as high as it is today. Code that could use wider testing > may be intergrated--code that is simply ill-conceived won't be. Right. That's exacly the point. egcs will be a place to test code that doesn't yet meet reliabilty/documentation standards and to bring the code up to those standards.