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,caa8ecf96e8cf189 X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Compiling gnat into gcc-2.8.0 Date: 1998/02/26 Message-ID: #1/1 X-Deja-AN: 328926549 References: <34F421F6.3A5FFF59@towson.edu> <34F5A906.1704@gsfc.nasa.gov> X-Complaints-To: usenet@news.nyu.edu X-Trace: news.nyu.edu 888520732 15654 (None) 128.122.140.58 Organization: New York University Newsgroups: comp.lang.ada Date: 1998-02-26T00:00:00+00:00 List-Id: Stephe says <> It would be *quite* a difficult project to make GNAT compilable with other than GNAT, and does not seem particularly useful. Even if you had a machine where some other Ada 95 compiler was available, and not GNAT (I know of no such cases currently), then you would probably find it much easier to do a cross-build than struggle with the incompatibilities. For example, the use of Unrestricted_Access is definitely important at some points, as is the exact conventions for external names. Remember that GNAT is much more than just an Ada program, it is an Ada and C program with intimate connections between the Ada and C, and the code definitely makes use of the fact that it knows that the Ada and C compilers are compatible. If one could not rely on this, then you would have to use Interfaces.C junk between the various pieces of the compiler, which would obfuscate large chunks of the code, and slow things down. There are *many* other reasons why this would be hard to do.