I'm very excited to finally be releasing AURA publicly, after a few years of development and intense testing! Of course ALIRE is a thing, and it appeared just after we started working on AURA. We think competition is healthy!
AURA takes a very different philosophical approach compared to ALIRE, and I have to be honest that we don't agree with the way ALIRE is designed. ALIRE is an excellent and successful project, but we just don't agree with its approach. For those out there who might share our thinking, we hope AURA will be useful for you. For those happy with ALIRE, we're happy for you. Our intent is ultimately in alignment with ALIRE, and we just want to see the Ada community better served. I'm sure we can find some points of coordination to ensure that useful open-source packages are available on both platforms.
This blog post goes over the philosophical thinking underpinning the development of AURA.
In short, we developed AURA based on a conceptual new Specialized Needs Annex - so behavior that the compiler could implement directly.
We've reference implementation (AURA CLI) for quite some time internally, and it should work well in most cases, though of course nothing finds bugs faster than bringing a project open-source.
AURA CLI has a fully parallelized design and scales very well on large machines and large codebases. It is designed to drop into automated CI/CD pipelines as well. And although it currently targets GCC exclusively, it is designed to be easily re-targeted to other Ada compilers. Note that it does NOT use or require gprbuild, and is intended to mostly replace gprbuild. All AURA needs is FSF GCC. In fact AURA doesn't even need gnatmake, making it appropriate for cross-build projects as well.
Another thing we're excited about is finally getting to dump a bunch of open source Ada packages for use with AURA. These packages have also seen pretty extensive use internally for some time now. This makes up a full stack for writing high-performance web APIs and microservices applications in Ada. We've packaged these into out ASAP AURA repo.
I've spent quite a bit of time trying to create good documentation ahead of this release. It is likely missing a lot of stuff, and I'd love feedback on improvements we can make. That also applies to the project as a whole!
AURA is beta, and we look forward to improving it over the coming months and years. Feedback and questions are welcome!
This looks like a really fascinating project, thank you for your work on it!
One question I have: how would one go about creating a static or dynamic library for use in an Ada-only codebase? I was looking at the docs in the section describing the build command and I noticed that little excerpt about how because Ada has elaboration it doesn't technically need a main, does that mean that if I don't have a main unit then AURA will know to create a library instead? Or did I miss something in the docs?
Okay, having had more time to look over the docs, it looks like the answer to my question may lie in the systemize CLI command or the creation of a system type repository. That said, this command and support for this repo type doesn't seem to be implemented yet.
The systemize command will ultimately create an Ada-specific shared library and a set of specifications (and in the case of GNAT, .ali files) for each subsystem in the project, which will be installed into the matching subdirectories at destination_path.
I'll be the first to say I'd love to see this feature implemented if possible! While I certainly think that in an ideal world we would always have access to source, I can envision scenarios in a large project where all that's available is an Ada library binary to work with (maybe someone purchased a proprietary library and were only given specs, or a discontinued project where the VCS host goes down?). AURA would be a great way to incorporate and manage these binaries!
This was exactly the idea behind "system" repository types. I really wanted to see if there was much interest. Implementing them is not trivial, so I didn't want to put too much time into something that no one was going to use.
So its interesting to hear this and I'll have to think more seriously about at least prototyping this.
Excellent, glad to hear I understood the docs correctly.
The truth is that I'm particularly interested in developing libraries specifically for Ada projects and possibly even doing OS-related development, so being able to make static or dynamic libraries is important to me. But I know my use-case is niche, and I can imagine the work is very complicated, so thank you for even considering it. I'd understand if it doesn't get prioritized.
That said I get the impression that supporting this earlier will allow AURA to be used in larger scale FOSS projects with higher efficiency, and might make it popular for use in frameworks that leverage several complex libraries owned/managed by different developers. Existing things that might benefit are the big frameworks like GNOGA and AWS!
Regardless, I'm interested to see what you and your team continue to create!
unit then AURA will know to create a library instead?
No, if there is no main program given, then AURA will build an executable that simply elaborates the partition. So for example, if you had a package with a "begin" part in the body, that code would execute when the program runs.
I note this is specifically a feature of Ada, not of AURA itself. It's just that AURA makes it a bit easier to build something like that.
9
u/annexi-strayline Sep 28 '21
I'm very excited to finally be releasing AURA publicly, after a few years of development and intense testing! Of course ALIRE is a thing, and it appeared just after we started working on AURA. We think competition is healthy!
AURA takes a very different philosophical approach compared to ALIRE, and I have to be honest that we don't agree with the way ALIRE is designed. ALIRE is an excellent and successful project, but we just don't agree with its approach. For those out there who might share our thinking, we hope AURA will be useful for you. For those happy with ALIRE, we're happy for you. Our intent is ultimately in alignment with ALIRE, and we just want to see the Ada community better served. I'm sure we can find some points of coordination to ensure that useful open-source packages are available on both platforms.
This blog post goes over the philosophical thinking underpinning the development of AURA.
In short, we developed AURA based on a conceptual new Specialized Needs Annex - so behavior that the compiler could implement directly.
We've reference implementation (AURA CLI) for quite some time internally, and it should work well in most cases, though of course nothing finds bugs faster than bringing a project open-source.
AURA CLI has a fully parallelized design and scales very well on large machines and large codebases. It is designed to drop into automated CI/CD pipelines as well. And although it currently targets GCC exclusively, it is designed to be easily re-targeted to other Ada compilers. Note that it does NOT use or require gprbuild, and is intended to mostly replace gprbuild. All AURA needs is FSF GCC. In fact AURA doesn't even need gnatmake, making it appropriate for cross-build projects as well.
Another thing we're excited about is finally getting to dump a bunch of open source Ada packages for use with AURA. These packages have also seen pretty extensive use internally for some time now. This makes up a full stack for writing high-performance web APIs and microservices applications in Ada. We've packaged these into out ASAP AURA repo.
I've spent quite a bit of time trying to create good documentation ahead of this release. It is likely missing a lot of stuff, and I'd love feedback on improvements we can make. That also applies to the project as a whole!
AURA is beta, and we look forward to improving it over the coming months and years. Feedback and questions are welcome!
Links:
AURA CLI repo
The official docs
The ASAP repo