Slashdot Mirror
What is the Ultimate Linux Development Environment?
nachmore asks: "I've been programming on Linux for a while now, always content to use vi for my editing and any debugger tools out there (gdb for C/C++, and so forth). As part of my SoC project I was working on Thunderbird (my first huge project on Linux) and I found that , although shell-based tools can do the job, they lack in easy project management, ease of debugging and other development features. I've only ever programmed with a GUI on Windows — and I have to admit that I find Dev Studio to be one of the few programs that Microsoft seems to have gotten (nearly) right. I've played around with Eclipse but find it's C/C++ support still lacking. So what GUIs would you recommend for Linux? I would like something with debugging (single step, step through, step-to-end, etc) support, CVS access and of course, support for large projects (e.g. Mozilla) and especially good support for C/C++. Is there anything really good out there, or is vi the way to go?"
...which religion is best.
vim 7 + cscope == awesome
thisnukes4u.net
emacs has all of these features that you are asking for: front-end for gdb enabling highlighting in source code for debugging, integrated support for source control including CVS, and incredibly good support for C/C++ syntax highlighting/editing. If you are coming from vi, you can even change the default keybindings to vi-style bindings.
I've always been a big fan of KDevelop, as to me (granted, a total newb) it seems pretty similar to large IDE's (eg Visual Studio), and it definitely does everything I need.
I use Visual SlickEdit 10 for Linux. http://www.slickedit.com/ This piece of software is the most configurable IDE I've ever used; it's a tad on the expensive side, but everything just works and it was worth it for me.
I've only ever programmed with a GUI on Windows -- and I have to admit that I find Dev Studio to be one of the few programs that Microsoft seems to have gotten (nearly) right.
I wonder. Which Dev tool gets it right?
Bet this
Absolutely -- that and Excel.
Anyway, as with a lot of things in Linux, you might want to take your preferred toolkit into account. (Since you seem to be asking about a RAD...) I personally love KDevelop, which is integrated with Qt Designer. If you want to use GNOME as a platform, there are tools that I haven't looked in on in a while but should be easy to find. Although back when the weekly KDE developer interviews asked about preferred tools, they mostly used Emacs, so take that for what it's worth.
(PS: to fend off flames -- I know you can write GNOME code in KDevelop and vice versa, but when last I tried, the cross-toolkit RAD wasn't there.)
What I'm listening to now on Pandora...
The best environment in Linux - as with on any platform - is a text editor and a solid mind that thinks the problems through before typing. IDEs inhibit that thought process.
Why? Did Steve find where we hid the chairs?
This is my sig. There are many like it but this one is mine.
Care to enlighten us on what was lacking with Eclipse and CDT?
My only real complaint is the large times it takes to recompile large projects. Slow indexing/parsing times for large amounts (1000+) of files are a given however for any type of tool that is going to cross reference new projects. However, if I have control of the project extraction of projects into logical subcomponents rather than editing huge single projects with Eclipse/CDT will give you a very nice time speed up.
A personal fave is that the debugger integration in eclipse is second to none.
somewhere on a nice beach on the west coast of Mexico and tall (or short) black haired, big round eyed girls bring you a constant supply of Negra Modelo and guacamole with habanero chilis...and of course using a Mac. Some Oaxacan sinsemillan would be a nice touch.
What?
By preference I use zsh, vi and make.Screen or multiple terminal windows (aterm by preference). Depending on the task and the requirements, GCC/gdb/ctags or perl/CPAN or boo+nmake+nunit. Throw in find grep and all the usual suspects in support. Tools with a command line interface preferred over ones without, commands that read from stdin and write to stdout by default perferred over others. Special exemption made for browsers and drawing programs.
If the structure of an application is too complex to manage under a unix command shell, that's a reflection on the design of the app in my book. I don't expect that's going to be a widely held viewpoint around here. Never mind, it works for me :)
Don't let THEM immanentize the Eschaton!
Given a large codebase that you are unfamiliar with, it's hard to start understanding the code with just Vi. It sounds like your ideal environment would allow you to pull a Mozilla project file into something like Eclipse or VS or KDevelop and have everything parsed out into structures, functions, methods, classes... You're not going to find that with the way Mozilla is built (at least the last time I checked). I think KDevelop does have the ability to parse autoconf files and set up a project that way, so you might be able to pull in parts of Mozilla that way. I think Anjuta might have a similiar ability.
I've since moved on from C/C++, but last time I checked the Eclipse CDT was getting a lot of work done on it. What is the problem with it these days?
Agnosticism. (ducks)
Though, actually, that's not far from my recommendation. Learn a bunch of different stuff. Learn vi and emacs, they both have their place. Spend some more time with Eclipse, I'm curious as to what you found lacking there? If you still don't like it kick around some of the other Linux IDE's. Hell even if you do like it kick around some that look appealing. Try some different frontends for gdb/vim/emacs/etc./etc. Just like anything, different tools are appropriate to different projects, and if you don't get too stuck with one (as seems to be the sad state of affairs for many here) you won't find yourself in the frustrating situation of trying to put in a nail with a screwdriver or hammer in a screw.
To fight the war on terror, stop being afraid.
Or xemacs if you prefer. I work on a large software system written in C++ and runs on various unixes (Solaris, Linux, SGI) and attempts to run on Windows (Windows usually doesn't agree with it). The system has thousands of source files and is built with make (the Makefiles are generated with imake!). Generally, I use xemacs to for editing. I love vi, but I tend to use (x)emacs because I find the buffer management (the ability to open multiple files) better than in vim. It's entirely possible I just don't know how to use vim right (vim's buffers seem to require that I save the file before switching to another buffer).
Emacs also offers easy access to our source control system (by corporate mandate, we use ClearCase, which I do not recommend to anyone wishing to maintain their sanity).
Finally, emacs allows me to open two (or more) windows in the same session. I generally put two windows next to each other so I can edit two files at once. This lets me open up files as I need them in either window, and then switch to that buffer in the other window if I need to get to it later.
Even though I consider myself a vi person, I've found emacs to be a very good environment for editing source files. It is very customizable and powerful. It adapts to how you want to use it (other people use it in vastly different ways), and generally gets out of your way to let you get your work done.
Just my opinion.
"Save the whales, feed the hungry, free the mallocs" -- author unknown
Visual Studio 2005 just rocks.. I only wish there was something remotely similar for Linux.
-- -- Warning. Do not stare directly at the sun.
Tool choices are clearly an issue of personal taste. And as my tastes clearly don't match yours, I won't be making any suggestions.
But I will say that, without exception, all the best developers I've known in my career (yes, every single one of them) work with a text editor and a shell window. They use GUI and web tools where needed or useful, but their minute to minute activity is spent at the keyboard, writing, running and reading code.
I submit that this is not a coincidence. The best developers write their own simple tools for small problems, and the proper environment for running simple tools is the command line. Great programmers work in varied environments and use diverse languages and configuration formats, where IDEs work well only within their target realm and are pretty much useless outside of it (e.g. no PHP mode in MSVC).
The benefit you get from fancy tools is real, but it's ephemeral. It make the typing of code (and maybe the reading of code) easier. But it does this by simplifying and obscuring the underlying details. Want to add a file to the project? Add it to this dialog. Need to check something in? Click here. Never mind how it all works, and hope that you never get tasked with doing something complicated (like an automated check-out-build-and-package script over a secure remote link).
By contrast, the understanding inherent in using your tools on the lowest level provides benefits all through the development process. These are the folks who won't think twice about writing a quick shell script to do the remote build.
So, by all means try out the fancy tools you can. But don't skip the part where you learn how to use the underlying tools well. Use the GUI stuff as an aid for the tasks you do understand, not as a substitute for what you don't.
"The best environment in Linux - as with on any platform - is a text editor and a solid mind that thinks the problems through before typing. IDEs inhibit that thought process."
Apparently posting to slashdot has a similiar effect.
For most things - assembler, shell, Perl, C, C++, SQL... Slick Subversion integration is a plus.
Sun Studio for Linux might be worth trying out.
you had me at #!
Tool choices are not just an issue of personal taste. There are tools which are better than others, and there are some tools that are worth a lot of money because of the productivity gains that experienced programmers can get out of them. This is particularly true of debuggers.
Disclaimer: I work for a company that sells development tools, including tools for Linux.
Some bugs can be fiendishly difficult to diagnose, particularly bugs that involve timing, resource usage, random events, and memory corruption. If you run into a bug like this and your tools consist of vi, a shell, and gdb, you are either going to spend months trying to diagnose it, or you will have to ship your program with a known defect. You could instead get yourself a trace-capable debugger, run your program in it while logging the execution of every instruction, wait until the bug surfaces, then step backwards through the program until the point where things start to go awry. I have used a debugger like this to solve problems that I would not be able to solve with, for example, Eclipse. I admit there are a lot of tools that make things easier by hiding the details of source repository checkouts and building projects, and I tend to avoid them in favor of the command line equivalents that can be scripted. When a tool provides me a better view of how my program works, it's worth using.
Seriously, KDE is very friendly to developers. You don't need Kdevelop.
Just a bunch of Kate and konsole sessions, spread over many desktops.
And kompose to have immediate access on any of them.
Also, the ability to launch immediately a konsole on any directory(F4 now ctrl-t on older versions)
is invaluable. And other than that vim for quick editing of project files(Makefiles, configure
scripts, etc...)
And yakuake can come in handy, since it is an unobstrusive and easy way to run commands.
Other than that,a healthy mix of traditional unix tools(cat, grep and sed is what I use mostly)
and a couple of python scripts to automate some tasks and even create on the fly graphical
components with Tk, to ease the management of your project.
http://recordmydesktop.iovar.org
I know this meets none of your criteria, and so completely fails to answer your question, but the best development environment I've ever found is Slime (Superior Lisp Interaction Mode for Emacs). It can work with several different Common Lisp implementations running on Linux, Unix, Mac, and Windows, and since Emacs is cross-platform, it can run on any platform where Emacs is supported. It provides a REPL, object inspector, debugger, single stepping, multi-thread support, stdout re-direction to the REPL buffer, syntax highlighting, auto-indent, expression evaluation from source files, error re-starts, and function cross-referencing, for those Lisps that support them. It offers capabilities reminiscent of the Fabled Lisp Machines of Old.
:)
Slime uses a component running in the Lisp process, and elisp code running in Emacs that communicates with the Lisp through a local INET socket. That means you can run the Lisp process on machine 1, set up an ssh tunnel to it from machine 2, potentially running a different OS, and connect to 1 from an Emacs on 2. I actually do this every day, connecting to a remote SBCL on Linux from both Linux and Windows. The interaction is fast enough that I routinely develop on the remote Lisp image over a WAN link.
The system works with any libraries available for your Lisp implementation, including database, web, and GUI toolkits, although it would be tricky do to GUIs over remote, and Open GL would probably have to be local.
Of course, there are some caveats... Developing in a Lisp is like working in another OS running on top of the host OS (especially with multiple threads). Also, Emacs doesn't have a drag-and-drop GUI builder, although one could be built in Common Lisp. And, you would have to develop a taste for parentheses.
--WH--
When it comes to FOSS there is no Ultimate, Best, Top, Only, or other perfect solution.
There are MANY excellent solutions which provide different pros and cons, to be considered by the potential user.
You must be recently freed of Windows where you are simply told what you want, here in the world of FOSS you have choices.
Reminds me of a lady who came to the US from Russia some twentyish years ago, when she saw a grocery store with CHOICES she flipped, couldn't handle the concept.
-Tim Louden
Interesting... when I first looked at the comments there were a few for vi and none for Emacs. Now there are many more Emacs votes.
So I guess we've finally found out which editor is faster.
*Disclaimer: I like Emacs, really. It's taking up 40% of my screen right now.
I am a joe fan, just a simple console editor and nothing else. I tried Emacs, and I liked it.
Now I'm using Eclipse for Java, and once you understand how it works, there's just too much to gain from it.
I don't browse the code, I navigate it. I don't navigate to files, I search for them. Go to declaration, forward and back editor navigation, automatic javadoc, automatic class and member creation, method extracting (yay!) are all features that, when combined, make an IDE that actually helps you build better code, faster.
Of course an IDE does get in your way, but Eclipse gives so much that it's worth it.
Debuggin with eclipse is great, it's the first debugger I'm actually using and liking since turbo pascal 5.5! (the VB6 debugger, I didn't enjoy that much)
I understand that CDT doesn't have as many features as the java stuff, but I think that going to Eclipse would be a good investment for anyone. You just need to adapt to it, and discovering features is not that difficult, you can start by printing a cheatsheet.
I'm sure emacs can do most of this stuff too, and way faster, but it does take more commitment.
Surprisngly, Netbeans has a really good C++ plugin. After many hassles and much searching for a good IDE, I have found that KDeveop is ok. Eclipse is decent at best. Anjuta tries to generate too much code. Currently, Netbeans works the best for me. It doesn't try to generate code, it has some intellisense features (if you liked that in M$ VS), and you can use a free collaboration account on sun's collaboration server, which can be very useful.
Emacs or Vi is really nice for development, but neither of them are an IDE.
Klingon Software is not released, it escapes, inflicting terrible damage onto the enemy as it does
If you're so die-hard that the built-in vi isn't real enough for you, why not?
Emacs can open a window for shell commands or to do a compile. Running vi is certainly something you could do. You could even bind it to a key.
When a tool provides me a better view of how my program works, it's worth using.
No offense, but if you need a tool to tell you how your program works, you've got bigger problems. Even in multithreaded code, with sufficient diagnostic output, you should be able to solve any bug. In all my time as a developer, I have yet to come across a bug that can't be solved by developing a mental model of the code (usually with the help of extensive telemetry) and working through things logically.
Rethink your desktop, abandoning the Windows-like defaults you were given. Do like the UNIX workstation users. Example:
Put a thick (50 to 60 pixel) gnome task bar at the bottom. Eliminate the one at the top. Put a 5x2, 4x2, or 3x2 virtual desktop selector thing on the task bar. Set your window policy to the traditional UNIX-style focus-follows-mouse. Never ever minimize, maximize, or roll up a window; simply spread them across the virtual desktops. You should use the traditional xterm, white on black, with the default font. (80x70 characters is good) A sharp LCD (native resolution, digital connector) is strongly suggested, at a minimum resolution of 1600x1024. Choose a fast-starting editor: original vi, joe (like WordStar), microemacs, or even (ick) pico. Linus uses microemacs; the source is on the kernel.org site probably under the name uemacs. Never use the file manager or file selector if you can possibly avoid it.
That's what the real hackers use, at least when the hardware is available. It's an upgrade from the "screen" program or the Linux console virtual terminals, without much change to the tried-and-true work habits.
You don't have to go with that exactly, but it's clear that your current setup isn't working for you. An IDE is a workaround, not a proper fix. An IDE only helps with one very specific task. A proper fix will make you more efficient at many other tasks. You might even start to like the gimp (zillions of windows instead of tabs) or set your web browser to open windows instead of tabs.
BTW, learn the extra tools. Valgrind usually whips gdb. You may also like ltrace, strace, nm, eu-readelf or readelf, oprofile, etc. Rarely will you find an IDE button to make these tools run. Learn the shell, really: you can do loops right on the command line, backtick substitution, etc.
I do this all the time, using a simple editor which is similar (text-only, fast-starting) to vi.
I just open 20 or more xterm windows.
Probably that seems insane to you. It is, if you don't free yourself from the Windows-style desktop. I can deal with dozens of windows with little effort by setting up a traditional workstation-style environment:
a. focus-follows-mouse, not click-to-focus
b. never minimize, maximize, or roll-up
c. 6 to 12 virtual desktops (use them all)
d. never use the GUI file manager or desktop icons
e. traditional xterm, white on black, default font
You'll want a native-resolution LCD (digital connector, not VGA connector) of at least 1600x1024. Go with 2560x1600 if you can afford it.
BTW, if you really need to actively edit all those files, see if the task might be scriptable. The sed and awk commands are great. You can use perl too, right on the command line instead of with a script file.
I agree, on Linux, I haven't seen anything better than Anjuta. I don't program GUIs however, I usualy create network applications.
KDevelop really annoyed me a lot, it was unusable for me.
Eclipse is great for java, but for C or C++ it really let me down.
Anjuta isn't perfect (but no other IDE I've ever seen is anyway), but overall it does most of what I want perfectly.
Computers are useless. They can only give you answers. -- Pablo Picasso
That's my experience too, actually. And it's also the way I worked back when I pounded code for a living, working with (actually working around) the big Rational APEX IDE, this on a project with well more than its fair share of studly coders.
I also fully agree with those who have emphasized code reading/understanding as the critical activity in software development. Things like ctags were a really important development. At the same time, I've emphasized the readability of the running text itself. I've heard some advocate that "the IDE will locate cross-references, etc for you" implying that all developers will have equal access to the IDE -and- the IDE will be fail-proof in finding cross references/relevant related information through its own code understanding. Rather, I think that the one-and-only thing you're guaranteed to get in a maintenance situation is the source code, so source code must stand alone in its ability to be understood.
dave
Conversely, vim also has all of these features and more. If you're coming from emacs, you can set vim to use emacs-style keyboard bindings, if you wish. Some emacs-style completion is supported by default.
My colleagues and I had an all out war (emacs vs. vim). In the end, we discovered that they are both just as feature complete and able to emulate each other quite well. Emacs could be a tad more efficient, as it requires more RAM, disk space, and CPU time than vim. It's a non-issue if you have enough resources. For us, it was an issue (flash drive).
In any case, if you are willing to invest the time to master either emacs or vim, I think you'd be best served. Graphical IDE's are often easier on the eyes, but I've yet to find one as customizable. All the features you'd ever need can be had in either of these two editors and they really are superb at what they do.
What happened to your previous declaration "as a Jaffa"? Couldn't resist the Ori-worshipper mod points, huh??
If you think the Visual Studio is a good environment there is no hope for you.
Stuff your arrogance where the sun doesn't shine.
I for one have been using Visual Studio for more than six years. I used 6, 7 and 8. 6 IS crap, yes. But the rest of your posting radiates ignorance. The typical UNIX way (make/emacs/vi/shell) is not The Way To Enlightenment. I don't use VS for code generation, I use it because it automates stuff I just don't want to handle all the time. Building? One click. Debugging? MUCH easier than with gdb. Quick overview & access to all files? Done.
I do develop for Linux, too, and it constantly bugs me that I have to switch to the shell, type make/scons/whatever, see the error output, switch back to the editor, look for the file in the file requester, open it, switch back to see the exact error, switch back to the editor.... vi and emacs are damn confusing, gvim is ok, but doesn't have a file overview panel like VS has. My favourite editors in Linux are kate, nedit and gedit, but none of them have all helpful tools VS has. Oh, and then there is gdb. Debugging multithreaded stuff with gdb - yeah right. gdb often simply misses breakpoints, does not find the source (even when I specified the exact path in the source command), watching variables is unnecessarily difficult etc. gdb is an absolute nightmare to use. ddd is better, kdbg is best, but debugging is one of the things where an IDE shines: since it has knowledge about the overall project structure and the files it consists of, debugging can be much easier. Then there are additional benefits, like refactoring tools (mostly in Java IDEs though - see IDEA).
This sig does not contain any SCO code.
Visual Slickedit is the best by far but you have to pay for it. I have used the Windows version professionally for decades and bought the Linux version when I got my first contract job using Linux. If you are doing serious programming, it is unbeatable. It is complicated enough to require some study to master it. It can be configured to work as a front-end for any command-line tools and the Linux version comes set up for all of the usual ones. It analyses program structure, parses compiler error messages and references them to the source text, etc. It does an excellent job of organizing large projects involving hundreds of files and many modules. http://www.slickedit.com/ Mike
Regarding Visual Studio and Microsoft programming in general. I use Visual Studio when writing code for Windows, but I dislike it for one of it's major strengths. I have heard it said that very few people really understand WIndows, and that most Windows programming is an exercise in cutting and pasting bits of code from a book, or the web, or whatever. There are several things I hate about Visual Studio. The first is the project wizards. They ask you a bunch of questions about the program you want to write, then generate 28000 lines of code. When compiled it has the look and feel of a windows program. A menu, populated with submenus and everything. That's the good news. The bad news is that you have to sit down and comprehend 28000 lines of code before you can take the next step. Assuming you still remember what the program was supposed to do. You immediately have a todo list of hundreds of things and you only just got started. You are already way behind. The second thing I hate about Visual Studoio is the Class Wizardry. If you really do understand Windows, you can sit down and hit a thousand buttons in a row, and write a complete program. I believe there are some people who can do this, but I never met them. What I hate the most about the wizards, is that their functionality is inscrutable. They touch a thousand things behind your back, and speaking of back, you can't back up. Using wizards is a one way deal. If you do need to back up, that usually means changing parts of the code by hand, that screw up future use of the wizards. Then there is the problem that the projects settings are kept in binary files, and there are so many binary files in a project, that its difficult to use source code control tools with any comfort. That's why I still enjoy programming with Makefile at the command line over using the Microsoft IDE. I know it's powerful, but too powerful for me. VS IDE is hooked right in to their knowledge base, but most of the knowledge base talks about ancient history like millenium edition or Windows 95. The minute you start using VS, the list of things you don't know starts expanding exponentially. I think I have said enough. Does anyone else have an opinion about something better?
Writing code in Linux is just as easy as writing code for Windows, but when it comes to debugging, there is just no comparison...Dev Studio smokes anything Linux has to offer by such a wide margin as to be embarrassing. It still astounds me that the Linux community has not come up with anything that can compare. I put this down to the whole OSS attitude of "Real Developers use VI/EMACS." Creating a top-notch development environment is extremely hard, and there are no good alternatives for Linux.
That all being said, if you are doing Java development, Eclipse is easily a match for Dev Studio.
Jens Wessling
Everything in emacs has a long learning curve - learning the keys, learning how to find out about the keys..., but it is mostly effort that you can transfer outside of emacs. I thought perhaps I was swimming against the tide with emacs, having been forced onto Windows for my desktop for some time, but then I discoverd XKeymacs - now I can use the emacs keys in almost any windows app, so I can edit in Outlook, Word etc., as if it's emacs. I only need to know one interface, and it's the most efficient one I've found. Almost all applications now appear to have "emacs lite" embedded in their edit areas.
Ironically, I installed Ubuntu, and found that most apps there used the windows keys (I know this must be an editable setting, but I haven't looked yet). So, as a hardcore Emacs user I'm actually much more comfortable on Windows than Ubuntu!
I personally find that IDEs make it far too easy to navigate around the code base, preventing me from ever really learning how things fit together. If you can memorize how things fit together from within an IDE, more power to you. I also feel that it's important to be able to perform various tasks without an IDE because eventually you will find yourself in a situation where you are not able to use the IDE (Going to the desk of a co-worker who doesn't have the IDE, working on a customer's site with whatever software they decided to provide you. etc) and if you don't know how to do things outside the IDE then you're pretty much lost. If you use the IDE as a crutch to avoid learning the tools that are available on the system, perhaps a career in marketing and sales would be more your speed.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Seriously, I'm suprised nobody has mentioned CodeForge yet. Seriously fast code completion lookup and tightly integrated support for source control won me over. Dl the free trial and check it out.
1. It Works
2. Qt
3. You can use Embedded Vim if that's your thing
Reasons enough for me never to come back to the stone age.
OTOH, if you can live with Emacs, it can be used as an IDE. (And an distro, too.)
Making laws based on opinions that stem up from false informations leads to witch hunts.
Have you seen UndoDB? It's a debugger, able to step Linux programs /backwards/ as well as forwards. Microsoft might have lots of eye-candy with Developer Studio, but with this tool Linux developers have a tool that lets then debug in a whole new way (and let's face it: most of us spend most of our time debugging, one way or another).
It uses gdb as a front-end, and adds backwards versions of commands like next, step, finish. It's also able to rewind the program to an aribtrary point in its history.
Disclaimer: I am one of the tool's authors.
I'm a big fan of Quanta Plus. Very nice for web developers/coders. --Vince--
I am working on a small (around 40,000 lines) 2D platform-style game in C using the Allegro library. I started the development last year in MSVC 6, because that was all I knew (before switching to Linux). Now that I use Linux, I learned vim, and enjoy it immensely for smaller projects, Makefiles, etc. Even though I found vim's taglist plugin, which allowed me to navigate between functions quickly like I had been used to, I found it insufficient for my needs. Eclipse CDK sounds nice, but I stopped trying to use it after about a half hour because it was far too bloated for my Dell laptop with a Celeron processor. I eventually settled on Anjuta, which I find amazing. I like how you can have it list every function in your project (distributed across multiple source files even) listed alphabetically on the left side. Autocompletion is nice, saving me typing time, and one key build + one key execution = saved time as well. I discovered Code::Blocks from this thread, though, and will investigate.
In the end, if I'm developing in C, I use: vim for smaller files, because it is better at moving text around, Anjuta for larger projects, because it is better at navigating through all the files/functions, and MSVC if I HAVE to because I'm on a Windows Only environment where I can't install anything else (like work!). The End.
https://libre2.adacore.com/gps/main.html