After months of building all tools from source and installing myself (a frustrating, but educational experience!), combined with vim, and other workhorse tools, I am wanting to try the other path.
As this will be done on a fresh virtual machine, there are not many constraints.
What are your recommendations for installing gnat studio, etc.?:
Any approaches to avoid?
Go “all in” on using Alire or not? (I hesitate to do this, have had trouble with repositories for Void Linux. In general, it feels “fragile”. But maybe I am wrong here.)
Should I do a custom rebuild of latest gcc-16 (with latest gnat, etc.)? Or use something else?
Any non-obvious tips you have?
In general, my goal is to be able to spend more time writing Ada code, rather than the care-and-feeding of associated tooling.
GNAT Studio installs pretty easily. Just do not take 2026.2. It is barely usable due to a massive bug. Install the previous release. It has issues, like disappearing cursor, but you could live with that.
I am using a range of GNAT compiler versions on different virtual or not machines to keep my code as much compatible as possible. It is helpful to run a 32-bit compiler from time to time. I develop under Windows, it is more comfortable and stable than Linux. Then I test under Debian, Arch, Ubuntu, Fedora, CentOS. Though not much. Ada is extremely portable and safe.
I never run for the latest compiler version and refrain from newest Ada features. I do not find them appealing and they are usually ridden with bugs.
I reduce generics to the unavoidable minimum. Generics never worked well in GNAT and probably never will.
There are problems with discriminated tagged types. When the inheritance tree gets deeper than 3 levels and you keep on adding new discriminants controlling a variant part, you will eventually crash the compiler. The nasty part is that it crashes quite late at the stage of code generation. So you might compile all files successfully for a long time and only when all files get compiled the compiler sends you back to the drawing board. It is quite annoying.
I do not use Alire. Gprbuid + native packaging offer more than Alire does. Neither provides a usable project management / automated release testing framework, nor I expect them to do it.
I do not use any “tools” except for the compiler and gprbuild. I do not find “tools” useful. I write documentation myself. I write unit tests myself. I turn off autoformatting and auto-indentation. I would turn off the annoying floating “help” popup window if I knew how. I do not care about highlighting. All I need from GNAT Studio is working “go to definition” and “find all references.”
And finally, will I live to see errors listed before warnings!
Thanks for your information here. Probably for similar reasons, I am wary of to relying on “towering levels of infrastructure”. They just break too often. Sometimes remaining closer to the ground-level can be better.
But, I am curious, what are the benefits that GNAT Studio brings to your set-up, as opposed to just using a working compiler and working editor? I mean what are the attraction points to GNAT Studio for you?
Tabbed view. I have 4 tabs side by side. It is extremely useful to see ads, adb and the client code at once.
Project view. I have deeply nested projects and source navigation through the project view is easy. I need not to care about actual folders. Moreover, the selected scenario filters out irrelevant files. E.g. the target OS dependent bodies.
I use search, messages and locations tabs at the layout bottom.
Search in files is very useful, I frequently use it for searching non-Ada files. Windows search is a disaster and the Linux one is an abomination.
Search within a selected project.
I like the ability to set up the run command arguments.
I use build/run selectors. My test projects have many main procedures. I can select the one I debug and build/run with a single button press.
Then of course “go to definition” and “find all references.”
Well, the debugger is unusable, but that is because of GDB, not GNAT Studio. I gave up visual debugging long ago. Last time I used it was under ObjectAda, then I could dive into an alien dynamic librariy. With GDB you would wait for a half an hour and get nothing in the end. Nothing compares with the DEC debugger, but that was in other century on other planet…
I’m not an IDE man. But, ever since GNAT Studio became much more reliable a few years ago, it’s been a pleasure to use, and unlike Dmitry who, I believe, develops on Windows, the graphical debugger works perfectly on Linux. So I use GNAT Studio for both 8-bit microcontrollers and 64-bit programs, with a fully functional graphical debugger in both cases.
It does not depend on the OS. The difference in the scenario. In my case it is a relatively small test program and a number of relocatable libraries in Ada or not. GDB seems uncapable to step into a library. I do not expect it to step into the libraries with MS symbols, e.g. to use pdb files, however ObjectAda did that. But it cannot even do that with the libraries built by the GCC toolchain with -g.
Afaik, GDB supports downloading symbol mappings for GCC sources and other well known libraries. In OpenSUSE it is enabled by default after a user prompt/confirmation. So even if the toolchain is compiled using release flags, GDB can step into the GNAT src and show everything. I suppose it should also be available for Windows too.
Just as a fyi to all. The GDB build by alire does not support interactive IDE debugging. I had to build/use my systems gdb in order to get interactive debugging.
Maybe we should not be providing GDB, as most/all systems have a way to install it with their own package manager… Maybe GDB from alire should be an empty package that just had the external GDB dependency…
I know, I tried that many times. Basically, I must type a very long chain of commands before even running a session, wait for a few minutes and … see hexadecimal code at best in the result.
This is not how visual debugging supposed to work. Provided there exists a way to make it work, then the IDE, not me, should do that.
I step into a call, I see the source or else disassembly + an explanation why the source is not available and prompt to enter a possible location of the sources. Considering Ada. gpr files should make it doable.
BTW, the same counts for symbolic traceback of unhandled exceptions. It is no fun to make addr2line work with libraries, especially on ARM targets. The IDE should call addr2line automatically and show the traceback in a separate tab.
Question, have you tried lldb? It is the debugger based on the LLVM infrastructure. I have never used it, but I would suspect it will behave better in Windows machines.
I do not remember. But my rule of thumb: if the debugger needs commands, it is not a visual debugger = useless.
There are simple reasons not to use such debuggers: Ada is a safe language. Ada allows safe design. Yes, you “can write FORTRAN programs in Ada.” Many do, I try not to. So, I do not have much bugs. Most bugs I fix are simple and therefore complicated debugging setups simply do not pay the efforts. Either the visual debugger does it through simple stepping and observing a few variables or else tracing is the way to go. Tracing is much easier than messing up with debugger commands. I wished gprbuild supported debugging code like FORTRAN’s D-comment but in a separate file controlled by a scenario with GNAT Studio fusing the code.
Complex logical bugs, race conditions, algorithmic bugs, leaks, live-locks are not for debuggers anyway. You would need a special testing setup with a combination of tracing and logging to get them located and fixed. GNAT exception tracing is very helpful. GNAT profiler and debugging memory pools are not.
I had problems with -Es, I do not remember the details. Anyway the problem is getting traceback from a library.
P.S. I rather catch exceptions and use this:
with Ada.Text_IO, GNAT.Traceback, GNAT.Traceback.Symbolic;
procedure Call_Stack is
use Ada.Text_IO, GNAT.Traceback, GNAT.Traceback.Symbolic;
TB : Tracebacks_Array (1..1_000); Len : Natural;
begin
Call_Chain (TB, Len); Put_Line (Symbolic_Traceback (TB (1..Len)));
end Call_Stack
