Add SweetAda to Alire about sweetada HOT 10 OPEN

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)

from sweetada.

@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

from sweetada.

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.

from sweetada.

@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?

from sweetada.

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

from sweetada.

@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

from sweetada.

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?

from sweetada.

@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

from sweetada.

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.

from sweetada.

@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

from sweetada.