-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add SweetAda to Alire #2
Comments
Hello @Irvise,
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. 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:
|
Dear friends, 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 |
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. |
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? |
yes. I tried to build the one from source forge. |
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, |
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? |
@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 Regards, |
The toolchain is here: https://github.com/alire-project/GNAT-FSF-builds/releases/tag/gnat-11.2.0-3 |
@Irvise 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. 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, |
We run all 4 cores in a very primitive way. Core #0 does nothing but wait the timer interrupt (and blink the GPIO LED) Core #1 output a dump of internal core parameters like the old single-core app Core #2 blink a LED on GPIO6 Core #3 just sits in a loop and bump a counter Note: do not attempt to perform synchronization primitives between the threads (by using mutexes) because the cores need heavy further initialization and address translation; just let them run independently so far.
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:
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.
The text was updated successfully, but these errors were encountered: