Best Practices for Setting Up a Multi-Targeted Alire Project

[Joebeazelman]

In the past, I have inquired about setting up a project to target multiple microcontrollers, each utilizing a distinct cross-compiler. This presents a unique challenge due to the varying hardware requirements.

Below is an overview of my project structure:

Hardware Project:

1. Core :

   • Contains operations and data structures. Operations invoke a hardware abstraction layer (HAL) responsible for interacting with the hardware at runtime.

2. Hardware Support Projects:

   • ESP32:
     • Contains ESP32-specific hardware implementations extending the HAL.
   • STM32:
     • Contains STM32-specific hardware implementations extending the HAL.

I am seeking guidance on finding an Alire-based project solution to this issue. I have been advised to maintain all projects as separate crates and “with” them together. This approach is effective when each project operates independently and can be reused. In my case, however, the projects are tightly intertwined.

What the best practices for building a mono-repo with or without external dependencies? Are there any real examples?

[godunko]

Is it "firmware" project? I mean that it produce few executables for different MCUs?

Do you have platform independent HAL layer? Or is HAL part of the MCU specific project?

[Joebeazelman]

Is it "firmware" project? I mean that it produce few executables for different MCUs?

Do you have platform independent HAL layer? Or is HAL part of the MCU specific project?

The HAL is platform independent and is part of the core.

[Joebeazelman]

Is it "firmware" project? I mean that it produce few executables for different MCUs?

Do you have platform independent HAL layer? Or is HAL part of the MCU specific project?

The HAL is platform independent and is part of the core.

Yes, it's firmware for multiple MCUs. One for each MCU, or board.

[godunko]

You can set one crate for each variant of "firmware" and manage common code by project files (as source directory of crate's project file, or create project file for core and "with" it in project files for crates). You can find how I handle it here:
https://github.com/godunko/a0b-examples/tree/main/blink_led

[Fabien-Chouteau]

Have the common code in a directory and then set up multiple crates that points to the common code.
That's what I did here with the device and simulator crates: https://github.com/wee-noise-makers/WNM-PGB1-firmware

[Joebeazelman]

I really like your approach. This is a big help in clarifying how to structure my project. Correct me if I'm wrong. In your case, the common code is in its own folder. Each platform, the simulator and device, are separate projects sharing the common code. Each project is built separately and independently by navigating into each one and performing an alr build

Note how I use the term project for what you call a crate. I presume you define a crate as simply an Alire project, whereas I mistakenly thought of it the same way--except it exists separately and independently of any other projects or crates. In other words,I assumed crates can't contain nested crates, but can reference them externally as a dependency.

Not sure how I reached this misconception, but perhaps it's because I've never encountered it until now, and because Alire can only build a single crate or project at time and that subcrates will confuse its context. It doesn't help that Git repos can't nest inside each other without resorting to subtrees and submodules. It's likely I was overthinking from a naive UNIX point of view.

What's the best way for building all the platforms at once? Do I write a shell script to navigate and build each subproject? I believe Alire has a project configuration where you can specify multiple crates. Will it do the same thing? Thanks.

[mosteo]

Alire doesn't yet support anything to aggregate crates to act on them together. This has been talked in the context of monorepos, but for the time being doing a bit of scripting is the way to go.

[Joebeazelman]

Gprbuild's aggregate project seems to perform a multi-targeted build according to the docs. I created a main project as an aggregate project and configured it for at least one project. Alire appears to build the project correctly, but when I add additional projects to the Project_Files, Gprbuild complains it can't find the second path. Not sure it's a bug or something else, but gprbuild only finds the first path specified.

aggregate project adb_controller is
   for Project_Files use ("./**/*device.gpr", "./**/*host.gpr");   // can't find second path, but finds the first
end adb_controller;

aggregate project adb_controller is
   for Project_Files use ("./**/*host.gpr", "./**/*device.gpr");   // swapped order, still can't find second path, but finds the first
end adb_controller;