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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Which old version is best to use?  don't trust Adacore anymore
Date: Fri, 24 Aug 2018 08:21:00 +0100
Organization: A noiseless patient Spider
Message-ID: <ly8t4wmdr7.fsf@pushface.org>
References: <2bd66110-61e4-45c2-b731-7387b45b1e56@googlegroups.com>
	<d9d368bb-7747-413b-9912-654e10884075@googlegroups.com>
	<9403f091-7a72-467d-aa6e-19a61c2d1f3c@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org;
 posting-host="c8f4dc218e1285883a529a6824557703";
	logging-data="31951"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19B/7Q7lU0xpSkOdeRos69kxQ5Kk4q0s/w="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (darwin)
Cancel-Lock: sha1:5yagsY+N4c6rLsnOeCN4SGAhdS0=
	sha1:ascv1VGC5DE9psuuz/bnAa3URVU=
Xref: reader02.eternal-september.org comp.lang.ada:54238
Date: 2018-08-24T08:21:00+01:00
List-Id: <comp.lang.ada>

patrick@spellingbeewinnars.org writes:

> It's not that I am missing a feature, it's just that I am tired of
> Adacore's games and I want to have independence from them. I feel like
> they are trying to make free Ada compiler options "demo-ware" for
> their expensive paid options.

Why are you surprised?

> The FSF version has a linking exception and would be fine if it wasn't
> so buggy.

I don't recognise this. How is it "so buggy"? Do you think that 3.15p
isn't buggy?

> I am looking at the Ada source code in vim with ctags and it is so
> well laid out and easy to follow along with.

It is possible to follow the GNAT source code with GPS/Emacs, provided
you construct a GPR for it (I've only tried this with a development
source/object tree; probably not that hard with an installed
compiler). Understanding it is a different matter.

>                                                       Maybe we could
> start maintaining GNAT independently of Adacore, I am sure the GCC
> people would not be opposed to patches.

GCC welcome patches (though the bar for acceptance is pretty high). Be
aware, though, that the gatekeepers for patches to Ada are almost all
AdaCore employees (how could it be otherwise?) and your patch has to fit
in with their plans. (Sometimes this means that the best is the enemy of
the good.) You stand more chance if it's a problem with the libraries or
with a particular build environment, rather than the compiler internals.

> As another side note, I am frustrated with Adacore but I don't want to
> direct any negativity at it's wonderful employees or the other GNAT
> writers who are no longer with us such as Robert Dewer.

Dewar