Re: Record operations (Algebraic Data Types and printing)

[Simon Wright <simon@pushface.org>]

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!