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: Record operations (Algebraic Data Types and printing)
Date: Mon, 08 Oct 2018 15:09:32 +0100
Organization: A noiseless patient Spider
Message-ID: <lyo9c4ttr7.fsf@pushface.org>
References: <0f5608ef-0038-491c-b15f-f67bcc76fae8@googlegroups.com>
	<g1pp2pFs7ajU1@mid.individual.net> <ly4le0kwpr.fsf@pushface.org>
	<e705fa87-61e3-498d-8c5c-8e7488410d7c@googlegroups.com>
	<46e2479f-a695-450f-a201-790015eddc87@googlegroups.com>
	<lyzhvrj9p4.fsf@pushface.org>
	<4986f84c-a05a-4eed-8ed5-37ea416b1a13@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org;
 posting-host="21229abb33dcef11bdf52816f08fd95a";
	logging-data="17309"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+ukkCpzy75Qm0Vp6NnotbiaTZ7yMVVueU="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (darwin)
Cancel-Lock: sha1:zCp+B7fyXQfdrq0Mu2w8LpYduEA=
	sha1:Oz+BlG5X4SGR0TxNMw4VHX2tFBc=
Xref: reader02.eternal-september.org comp.lang.ada:54512
Date: 2018-10-08T15:09:32+01:00
List-Id: <comp.lang.ada>

briot.emmanuel@gmail.com writes:

>> I find libadalang a bit distressing, mostly because of the extensive
>> reliance on external Python utilities: from REQUIREMENTS.dev,
>
> AdaCore just announced they would be packaging libadalang with the
> compiler with the 19.1 pro release in February. So maybe also with the
> GPL later this year (which, from memory, is based on the x.1
> release). That will indeed make things easier, since indeed right now
> everyone has to develop their own scripts to recompile all
> dependencies.

I was being purist|picky|annoying really, having wanted to think of
AdaCore as an Ada shop.

That said, I pulled the latest libadalang.git: there are instructions in
README.md. It's easy enough to fetch and install all the Python parts.

It's not that it's difficult to build the compiled parts of libadalang,
which I guess you'd only do if you wanted to use the latest version from
Github for whatever reason; at which point you encounter the sort of
problem I found, where it uses a new interface in a library (turned out
to be libgpr in this case). OK, I was using FSF GCC 8.1.0.

May I say at this point how very much I agree with Randy about not using
'use' if at all possible! If an interface isn't present in your version
of a library then no amount of searching in GPS/Emacs via your project
file is going to find where it ought to be.

GNAT CE 2018 includes libadalang; not sure what scripts are included.

Maybe I should consider (for my Mac friends) a GCC 8.2 release including
libadalang!