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,ef949f5a82347361 X-Google-Attributes: gid103376,public From: David Starner Subject: Re: How to build gnat on top of egcs-1.1.2, please? Date: 1999/05/05 Message-ID: <37305FDB.44385920@aasaa.ofe.org>#1/1 X-Deja-AN: 474352197 Content-Transfer-Encoding: 7bit References: <372FE594.818795BA@here.org> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Oklahoma State University Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-05-05T00:00:00+00:00 List-Id: "David C. Hoos, Sr." wrote: > On Wed, 3 Feb 1999, Juergen Pfeifer wrote: > > - Should we by default build packages based on egcs? > > For the time being, I recommend the answer should clearly be: no. The answer should probably be no. EGCS produces better C & FORTRAN, and is far more C++ standard compliant than GCC 2.8.1. If you don't want to mix versions, and Ada relibility is not very importatant, then go with an EGCS solution. > Egcs is also a > quickly moving target, and Cygnus has already an internal not yet > released new source tree that is very different from the currently > published source. In article <7g3klg$26p$1@rtl.cygnus.com> on gnu.misc.discuss & comp.lang.ada, on 04/26/1999 Per Bothner wrote > > Well, I can't think of a single Gcc feature, major or otherwise, > that was in our standard customer release before being in EGCS. > Note: I am talking about the standard GNUPro product; not > contracted deliverables made to a specific customer. (Obviously, > if somebody pays for a new port to an unannounced chip, we are > not going to put into Egcs before it is announced!) But in > general, customers do *not* get major features before Egcs. > > Since we merge *from* Egcs to our internal tree, rather than > vice versa, the check-in policy at Cygnus is: Nothing gets > into our internal tree unless it is in Egcs *or* specially > marked as being Cygnus only or "sanitized". That should make > it obvious that the default is to check things into Egcs > first or at the same time. Unless Cygnus is openly lying about the matter, I'd say this myth is clearly false. > > There is nothing wrong with experimenting with building gnat on egcs, > but the result should be treated with extreme care and should NOT be > what we should offer to inexperienced new users as an easy to use > package. Why not easy to use? It's easy to use as GCC 2.8.1, and much easier if you're trying to mix versions. > Egcs is an *experimental* compiler and they really mean it this > way. Experimental in method (bazaar), not in style. It is replacing GCC as the GNU compiler, so it's obvious RMS considers it a successful experiment. > Gcc 2.8 is a pretty damn good code generator already and egcs does not seem > to contain any Ada-specific code generator improvements. That's part of the point of a common backend, that you don't need to make many Ada-specific code generator improvements.