I am having some trouble with my recent pull requests for the Pi-Ada-Tutorial regarding Windows compatibility. Everything builds and passes the GitHub Actions CI perfectly on Linux and macOS, but Windows is blocking the PRs.
Here is the exact breakdown of what is happening on Windows:
In GitHub Actions (CI): Both light_tasking_rp2040 and embedded_rp2040 fail to build on the Windows runner.
Locally (Windows):light_tasking_rp2040 actually builds fine on my machine, but embedded_rp2040 fails locally as well.
If anyone here has experience debugging Alire/Raspberry Pi Pico cross-compilation environments specifically under Windows, I would really appreciate your insight.
(Note: There are quite a few pull requests open right now. I initially opened a single PR for the Pi Ada Tutorial release 1.7.0 to save the moderators some work, but when the Windows CI failed, I split it into 10 separate pull requests—one for each crate).
The error message that is happening on the Alire Index Windows CI is this:
rp-timer-interrupts.adb:7:06: error: "ADA.INTERRUPTS.NAMES" is not a predefined library unit
It feels like the build of rp2040_hal can’t see the libgnarl sources for some reason, even though I can see libgnarl being built in the logs (a-realtim.adb is getting compiled, for example).
For context, the runtime is split into two libraries: libgnat for the sequential (non-tasking) stuff, and libgnarl for the tasking stuff. They are built by the projects runtime_build.gpr and ravenscar_build.gpr respectively. It feels like the build of rp2040_hal is not able to see the libgnarl part of the runtime for some reason, though I don’t know why that would happen on Windows only.
Could you try adding this to the top of your GPR file (e.g. pico2_ada_c07_buzzer.gpr):
with "ravenscar_build.gpr";
Usually, Alire should auto-with this file in its generated *_config.gpr file, but I’ve seen cases in the past where it does not do this which has caused problems. The instructions on the runtime crate’s page state to “with” both runtime_build.gpr and ravenscar_build.gpr, so adding it explicitly might help with this problem too.
That’s a shame. It was a bit of a stab in the dark anyway.
Since you’re able to reproduce it locally (at least with the embedded_rp2040 runtime), here’s some ideas for other things you could try to help narrow down the cause:
try downgrading the runtime crate version to 15.3.0. As far as I know, this problem has only ever happened with the most recent version (15.4.0)
try forcing a clean build with alr clean and then alr build to see if that makes a difference.
It’s very confusing why this happens on Windows but not Linux, and why there’s a difference between your local Windows and the CI (at least for light_tasking_rp2040). It doesn’t seem entirely repeatable.
The only possible thing I can think of is that it’s something to do with how the runtime handles multiple variants of package Ada.Interrupts.Names (one version for single-core and another for multicore). Normally, the filename is a-intnam.ads, but the ravenscar_build.gpr file uses a for Spec ("Ada.Interrupts.Names") use clause to select between two files: a-intnam-1.ads and a-intnam-2.ads depending on the chosen configuration.
If, for some reason, the compiler doesn’t know about that file renaming clause when building rp2040_hal then it will probably look for a file called a-intnam.ads which doesn’t exist, and so it thinks the package doesn’t exist.
But then the question is why does this only happen on Windows and not Linux? And why has it only started happening now? Very strange…
That’s the “alr dev” CI that uses the 3.0.0 development version. The Alire index actually runs two Windows CIs, one with the latest release version (2.1.0) and one with the development version (3.0.0), presumably for some kind of testing with it.
In any case, both 2.1.0 and 3.0.0 exhibit the same error in their logs.
Seem that the last step to fix the problem was to move the minimum requirement for pico_xbsp from 1.6.1 to 1.7.0. Now it compiles. Even the .EXE problem on windows is fixed so the Pi-Ada-Tutorial crates are now green.
There should be no difference because a 1.6.1 was meant to be a prerelease to 1.7.0 to disentangle dependencies for the GitHub-Worker. But you bring up an important point so I’m going to diff them to see what the sneaked in anyway.
Which is optional and needs to be activated. With most demos don’t because they don’t need the overhead of routing the IO through a protected object. And, of course, the spec stayed the same.
There are also unit tests. But GitHub should not compile them as they are can’t be executed without a Pico.
But the really disturbing part is that the problem is back:
@mosteo was able to review two crates and then it returned.
Now it compiles. Even the .EXE problem on windows is fixed so the Pi-Ada-Tutorial crates are now green.
I’m sad to report that it only apparently succeeded because I reviewed (mistakenly) out of order and 1.7.0 was not yet in the index, so all builds silently failed with missing dependencies (this is considered currently a pass in the index checks because otherwise lots of people complained about not being able to do anything about 3rd party dependencies that failed in some platforms only).
So, when I merged 1.7.0, the Windows error returned, but I know about it so that’s not a blocker. There should be a fix for it in `alr 3.0`.
Having seen how the bare metal runtimes are committed “en-block” I have changed my workflow so when I have to commit multiple crates I can do that do that en-block as well. So they all become active at the same time.