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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,344332f209947007 X-Google-Attributes: gid103376,public From: Jonathan Guthrie Subject: Re: Gnat Free ? Date: 1998/10/19 Message-ID: <70e04a$7bc$1@news.hal-pc.org> X-Deja-AN: 402630171 References: <6volj0$250$1@uuneo.neosoft.com> <3620F843.39465221@home.com> <3621E42C.2920@Entenhausen.net> <700rfc$6h4$1@nnrp1.dejanews.com> <3627196D.720A@Entenhausen.net> <708040$4h4$1@nnrp1.dejanews.com> <87pvbs6zb3.fsf@yakisoba.forte-intl.com> <708n5d$7ds$1@nnrp1.dejanews.com> <70bgao$j7i$1@news.hal-pc.org> Organization: Houston Area League of PC Users User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (Linux/2.0.34 (i486)) Newsgroups: comp.lang.ada Date: 1998-10-19T00:00:00+00:00 List-Id: Finally! While I appreciate all the people who have made suggestions directed toward helping me get a copy of this working, what I REALLY want to talk about is the consequences of basing your compiler on someone else's compiler that is being actively developed. For those of you who have made suggestions, I have already tried some of them, I may try others, later. Brian Rogoff wrote: > On 18 Oct 1998, Jonathan Guthrie wrote: >> dewarr@my-dejanews.com wrote: >> > We are perfectly aware that there are enthusiasts who would like to get their >> > hands on the latest technology, and don't care if it has problems. But that is >> > not the public we are addressing in making public versions of GNAT available. >> Actually, the biggest pain in the neck with GNAT is the fact that ACT >> doesn't update the GCC patch files between public releases. > This is a legitimate gripe. However, in your case, as someone who is > "just" using GNAT to learn (no disrespect intended!) the solution is to > install a standalone version of GNAT which doesn't interfere with the GCC > you are using to do real work. Disk space is cheap, no? "Standalone version"? You speak a strange dialect, sir. What do you mean? It's been too many months for me to remember why replacing gnatmake (gnatbuild? that's gone with the mists of time, too) with a version that calls gnatgcc instead of gcc (the fix I applied to get g77 and gnat to coexist) didn't work in this case. Is that similar to what you're talking about? >> While I don't think there's anything wrong with only making a release of >> the free compiler every once in a while, (I so rarely update compilers >> without being forced to that I'd never notice,) I think that when you base >> your compiler on somebody else's, you should accept the burden of making >> sure that the available free release of your compiler works with any new >> releases of the base compiler soon after the release of the new version of >> that compiler. > I roughly agree, with the caveat that I'd qualify the last sentence to > only include stable new releases of the base compiler, since there have > been quick fixes after new GCC releases, and I'd rather ACT be focused on > improving GNAT rather than tracking each miniscule patch to GCC. When make the choice to use the Gnu C back end, you gain tremendous advantages. There is no need to write a code generator or to port that code generator to new platforms. Since Gnu C is already popular and has been ported to a wide variety of platforms, you get easy (well, easier) porting to those platforms and since there are numbers of people improving parts of the compiler, including the optimizations and code generation, you have a realistic hope of getting good code out of that back end. However, those benefits have a price. The Gnu C people can easily screw you up, even if only by accident. To avoid that, there needs to be coordination between the you and the Gnu C maintainers. I would expect that this coordination, which I have reason to believe IS going on in the case of GNAT, would result in two phenomena: First, the number and significance of patches to be made to the existing Gnu C back end should decrease with time as they are integrated into the base Gnu C source set. Second, the number of large changes to the function calls that constitute the front end/back end interface should also decrease with time. The consequences of the decreasing number of patches to the back end are, I hope, self-evident. The lack of changes to the calling conventions should mean that the front end source does not have to be patched in the event of any likely back end changes. That means that, ideally, there is NO effort to "port" GNAT to a new version of Gnu C. Until ACT reaches that ideal, some kind of judgment has to be made about how much effort goes in to keeping the distributed source for the front end up with the changes someone else keeps making to the back end. I agree that it probably isn't worthwhile to make a patch file for every release, that it probably isn't worthwhile to update the GNAT source at all between GNAT releases because of changes to Gnu C, and that the changes to the Gnu C patch file would necessarily be released some time after the version of Gnu C which they patch, but Gnu C V2.8.1 has been out for seven months and (to my knowledge---I quit looking in May) no patch file for has been made for it. -- Jonathan Guthrie (jguthrie@brokersys.com) Information Broker Systems +281-895-8101 http://www.brokersys.com/ 12703 Veterans Memorial #106, Houston, TX 77014, USA We sell Internet access and commercial Web space. We also are general network consultants in the greater Houston area.