I maintain Emacs ada-mode, which has some Ada code that users must compile. The biggest source of problems reported by users is incompaiblities among the AdaCore packages and compiler versions. Having only one distribution to deal with makes this much simpler, especially since the Alire ada-mode package can specify what versions of dependencies to use. I can provide the Alire package - i can’t provide packages for all of the other distributions.
I do feel strongly about keeping things (like AdaControl) available in an OS package manager, so I speak up. But more will be needed to make that a reality…
I do not feel strongly to keep these things available in the OS package manager. I’m ok with using “apt install gnat” and “apt install gprbuild”, and then also install vscodium (https://vscodium.com/) together with the Ada extension for writing Ada code. I use a virtual machine with GNAT Community Edition 2019 for using AdaControl which is then already a very powerful version of AdaControl. I really love GNAT Studio but it may be hard to build from sources and thus hard to maintain for a package manager. What I think is important is that it should be super easy to get started with Ada development on a platform.
Thanks Stephen, I didn’t interpret it like that but I believe you are right. What’s important is that it should be easy to get started. Inspired by your message I installed alire and tried it out. Very easy to get started. Even removing gnat and gprbuild from debian packages is OK for me too.
I certainly didn’t read it like that. AdaCore have no real influence over what ends up in Debian; if Debian are removing their FSF GCC releases and tools that’s their decision alone.
I understand that maintaining that packages is a lot of work and getting use to Alire will help a lot. But I will miss the debian way of installation. Alire is missing a guide on what to install to have a nice platform to start with Ada/SPARK and I used AdaCore’s latest community package to get some hints what might be missing.
It may be coincidence but I had issues with the debian packages compared to Alire. Of course not all projects are meant for Alire yet. That aside. I do think that having an Alire binary in the repos might serve as an Ada advertisement when users are searching in a package manager.
I want to speak up because Adacontrol is now exceedingly difficult to install from debian. The older compatible gnat CE edition can’t be installed from the repo anymore, nor can adacontrol itself, or the asistools. I tried to compile both the version using gnat ce, and the one for the separate asistool (correct me if I’m wrong), but always it requires some version of asis and gnat, that are not available. Also the Adalog’s website very silent, as is its twitter account, for a few years already.
JP.Rosen is still alive so I wonder what happens.
It’s certainly a deplorable situation for a beginner, as the tool doesn’t exist in alire.
The site mentions that adacontrol can compile with the asistool package provided to users to gnat pro, and that it has the GPL licence, so users don’t need any kind of permission to diffuse it, eventhough Adacore doesn’t. So… can’t someone who has it just give to everyone else ? Users of gnat pro, please step up and do your duty.
ASIS is an interface to a particular representation of the compiler’s AST. ASIS support was removed from GNAT because maintaining this interface required a fair bit of maintenance and made modifying the compiler’s internal AST more difficult.
AdaControl depends on the ASIS interface, so it cannot be built with a recent GNAT.
I believe AdaCore’s paid ASIS tool is just an older version of GNAT with a support contract.
Libadalang is AdaCore’s recommended replacement for ASIS, which provides an interface to an AST independent of the compiler version. However, this interface is significantly different from ASIS and would require nearly a full rewrite of AdaControl, which would be a significant effort. I don’t think anyone is willing to pay for this work and no one with the requisite skillset has volunteered.
If you really need it, you can install an old version of Debian in a container or VM and run AdaControl there. This is not ideal, but it’s what’s available.
JP Rosen told me that he intends to bundle the older GNAT version and his progfram, and put them on alire. Yes I understood that there were technical reasons to switch to something else. However there are just none to not make the old package available as it was. Let the community decide what they find useful. This is making things complicated for no reason. Moreover, because it’s Rosen, they certainly know, and so must be refusing wilfully to accede his request.
Sorry, but I’m very bad at social networks. I never check the twitter (sorry X) account, and I didn’t update the website because nothing new happened. TBH, I’ve been discouraged by the poor quality of LibAdalang. Consider that it took 5 years for AdaCore to move Gnatcheck from ASIS to LibAdalang!
Libadalang, and the underlying langkit, and lkql are great technologies used in many of AdaCore tools (Ada language server, gnatformat, gnatcheck, gnatkp, gnatcoverage, gnatfuzz, gnattest, etc.).
Within recent editions of GNAT Studio, the language server (then, libadalang if I understand correctly) does a great job. It clearly understands “at best” in-progress and sometimes incomplete changes (new types, new functions, renamed items, …) across multiple editor windows, even unsaved, and that immediately and independently of GNAT & GPRBuild (no rebuild needed).
But perhaps AdaControl needs some details that only a real compiler sees?
My impression is that libadalang and ASIS (or any API that can make the compiler’s “brains” accessible) are similar but still different kind of tools.