Add SweetAda to Alire

[Irvise]

Hi Gabriele,

I have already talked to you about this, but I want to make it a bit more official. I would like to see SweetAda added to Alire. Now, what does that mean?

Alire and the new version 1.1.0

Alire is the "new" "shinny" "great" official package manager for Ada from AdaCore. I am not a great fan of package managers, but they to help with project management and quick testing/sandboxing.

With the new version, which is still not out, it is in RC phase, Alire will have binary releases of toolchains (FSF as announced). That is great. And I think SweetAda can capitalise on this. Since SweetAda deploys Ada in anything that can be supported by GCC and you yourself, having it in Alire, with binary toolchains would be a terrific thing.

Explain me more, how and who will do this?

Long story short, I think it would be great to have the entire SweetAda project and toolchains available in Alire. This would make working with SweetAda a seamless experience. No need of several downloads, of complex setups. In theory, a user would be able to simply say: "My project requires support for the Raspberry Pi 3, I will add SweetAda to my project:,

Sooo... how can this be done?

I have been thinking about this, and this is my proposal:

• If there are any common files to the different architectures, have a root package named "sweetada". All other packages will depend on it.
• Create a different package for each architecture. For example: "sweetada_riscv", the will depend on "sweetada".
• For board specific files, another package could be added, such as "sweetada_raspberry".

For the binary releases of the toolchains, I am not knowledgeable enough to comment.

That is a lot of work, who will do this?

I hope I will have some free time in the coming weeks and I would like to try my hand at it. I am currently learning Alire myself.

Closing thoughts

What I just wrote is, obviously, dependent on your comments and your indications.

@Fabien-Chouteau what is your opinion about my proposal? I am specially interested in your opinion about the toolchains.

[Fabien-Chouteau]

Hello @Irvise,

@Fabien-Chouteau what is your opinion about my proposal? I am specially interested in your opinion about the toolchains.

I was expecting this question to come sooner or later ^^

My first comment is that, based on my understanding, SweetAda looks to aim at providing a full Ada development solution. So I am not convinced it will fit in the Alire workflow. What I see in the repo is a worflow based on configure scripts and Makefiles, not the Alire way. That being said, it can probably be done for the libraries of the project.

About the toolchains, I need to know more about what is done in SweetAda. I don't see the build scripts for the toolchains here.
For instance, the toolchains have sweetada in the target triplet (e.g. arm-sweetada-eabi), why is that? Can a standard arm-none-eabi compiler be used with SweetAda?

To give a bit of context about toolchains in Alire. Alire is not really made for binary distribution, and in a ideal world where GNAT would be available in every Linux distribution, and Windows msys2, etc. we would prefer not to distribute toolchains with Alire. We decided to do it because, unfortunately GNAT is not available everywhere (especially the cross compilers).

Since the distribution of binaries is more delicate in terms of security for the users. We have some rules about what we include in the Alire toolchain distribution:

• Public sources and official releases of projects (GCC, GDB, etc.)
• Public build scripts managed in the Alire project
• Binaries compiled GitHub Actions (reproducible setup, does not depend on one person's machine)

[gabriele-galeotti]

@Irvise
@Fabien-Chouteau

Dear friends,
I am having actually a brief vacation time far from home. So I will make the story short and dirty. We will go in deep in the next days, if you want.

---

Yes, SweetAda, in its first incarnation, looks at a development environment. Maybe something better in the future, who knows.

I do not know Alire well yet, and I think is too early to talk about integration. SweetAda is lacking low-level basic functionalities for many CPUs, and many other things, and this is my current priority.

---

About the fragmentation of a SweetAda distribution: SweetAda is designed to natively "scale" well. Just wipe out CPUs and Platforms directories, but the ones you are interested in.

E.g., If you want a SweetAda for RISCV, just keep the cpus/riscv directory and platforms/HiFive1.

---

Toolchains have nothing special, and "sweetada" is here because they are the "official" toolchains for SweetAda, but it's only a name. They are plain builds from FSF sources. Using your own toolchain should work, providing you are setupping it in the configuration files as the standard toolchain. Also, rename RTS directories, but I'm modifyng the Makefile to remove even this eventuality.

Just the GCC/GNAT wrappers are two small exotic executables, but they carry no interesting things, they are version-independent wrappers. I will make the wrapper sources available ASAP along with SweetAda. So far, just rename 'em to "port" 'em to your toolchain, it should work ok. Note that some SweetAda/RTS code virtually requires Ada 2012/2x features.

---

Yes, build scripts do exist. But they are tied to my setup environment, and have to be rather generic, with tens of configuration files and variables. If I have to provide them, then people should be prepared to install cross-compilers, countless support libraries with the right version and setup, and the like.

Let me say, managing 3 x (cross-compiler + OS environments + countless libraries) + (18 x 3) cross-compilers, it's just a waste of time and will confuse people, and is surely calling for further problems on my side. It's reinventing the wheel, and it's just a huge project on its own.

And, as I said, SweetAda toolchains have no intrinsic specialities, you could theoretically use your own toolchain. The only important thing is the configure line, and you can see it by running the gcc executable.

Furthermore, as you said, perhaps SweetAda toolchains will totally cease to exist if GNAT compilers will be widely available in an OS distribution.

G

[Joebeazelman]

I think ALR can make use of the AVR toolchain. Currently, building the AVR toolchain is extremely frustrating and has difficulty locating its dependencies. I was unsuccessful building it and had to switch to stm32 mcu for my project.

[Irvise]

@Joebeazelman

Hi,

which AVR toolchain where you trying to build? Building gcc-avr is rather simple and easy, just like creating any other xcompiler for any other architecture. Are you referring to avr-ada?

[Joebeazelman]

yes. I tried to build the one from source forge.

[Irvise]

@Joebeazelman

That one is rather tricky to get working. I have built is successfully a couple of times and in the end, you always need to know what the recommended build script does. If you just need an AVR toolchain and not the avr-ada runtime libraries, then I would recommend to use what Alire provides or the AVR toolchain from SweetAda. If you need some runtime support, if SweetAda suffices, then I would recommend SweetAda.

Cheers,
Fer

[Joebeazelman]

Thanks. I don't know why I couldn't find it before. So the AVR toolchain has to be built and somehow integrated into ALR or is it standalone?

[Irvise]

@Joebeazelman Yup, it was added to the GNAT-FSF-builds repo which is what is used to create the toolchains for Alire.

However, I do not seem to be able to find it... @Fabien-Chouteau could you help us here? I ran an alr toolchain --select and the avr toolchain does not show up... I am using Alire v1.1.1. Is that expected? I did an index update by I saw nothing there regarding the AVR toolchan...

Regards,
Fer

[Fabien-Chouteau]

The toolchain is here: https://github.com/alire-project/GNAT-FSF-builds/releases/tag/gnat-11.2.0-3
I am waiting to have some feeback on usability before putting it into the index.

[gabriele-galeotti]

@Irvise
@Joebeazelman
@Fabien-Chouteau

Hello.

I repeat once again for clarity and let you understand in order to pick the one useful for you, SweetAda toolchains are plain builds from FSF. There is nothing special.

They are generic cross-compilers running on decent 64-bit machines under OS like Linux or Windws.

They include binutils, C cross-compiler, an Ada cross-compiler, GDB and support libraries. You can use it in every context.
The name -sweetada- is only a prefix name for a toolchain, like -mingw64- or the like. It is just too difficult and time-consuming to create and provide the whole build system for all the toolchains.

Furthermore, in the context of SweetAda, every toolchain could be used. I changed some procedures in the build machinery in order to allow an agnostic use of a toolchain. Just the wrappers are useful for maximum efficiency of the SweetAda build system, they do not depend on toolchain, and they can be easily build from sources or directly downloaded as executables.

Best regards,
G