hirtos 2.0.0

[jgrivera67]

Created via alr publish with alr 2.0.1

Updated HiRTOS crate to version 2.0.0:

• Added RISC-V port for the ESP32-C3 platform
• Code refactoring to make other ports easier

[mosteo]

I'm not sure if this is what you want, in light of the comment at the top . This is freezing the cross-compiler and the CPU_Core variable for all clients of this library.

[jgrivera67]

If I don't freeze the cross compiler to either cross-compiler, I will not be able to pass the required builds, as this crate does not build with the host compiler. Although I'm freezing the cross-compiler to gnat_arm_elf in the crate's alire.toml, in the README of the crate's repo (https://github.com/jgrivera67/HiRTOS), I explain that in order to compile it for RISC-V, the cross-compiler needs to be changed to gnat_riscv64_elf. Would it help if I put that comment in the alire.toml file? Or is there a better way to do what I need?

[Fabien-Chouteau]

You cannot ask people to change the cross-compiler of a crate that is in the index (a release), because they are immutable. If you set a specific compiler target in the manifest people won't be able to use your crate for another target.

You should set a dependency on the virtual crate gnat, like gnat ="^13.2.1". Then, the projects that use this crate will either set a dependency on gnat_arm_elf or gnat_riscv64_elf.

The fact that the build tests won't pass is a limitation of the current automated testing in the alire-index; since we are aware of this, we will accept the release.

[mosteo]

Expanding on Fabien's advice, if you want to pass our checks for the added peace of mind, you can have a nested crate that does the build and forces one of the cross-compilers. Then, in your main crate you define a test action (look for actions in the spec) which is what the CI checks will run through alr test.

[jgrivera67]

Thanks Fabien and Alejandro for your comments. I have updated this PR accordingly. However, I'm not able to pass the CI builds. I added test actions and verified that they run fine locally, but CI builds fail. I tried with and without a dependency on the virtual crate "gnat ="^13.2.1", but no luck. Am I missing something?

[mosteo]

Thanks for the revised version, @jgrivera67. I have to check what is the problem with the missing compiler in the tests, it may be related to a recently reported bug. I'll come back to you if needed.

[mosteo]

Hi @jgrivera67 , could you take a look at the error here? I don't think this is caused by our CI setup, I can reproduce it locally when I alr build the sample_apps/fvp_armv8r_aarch32_hello crate.

[jgrivera67]

Hi @mosteo, thanks for checking this. The problem was on my side. I was using the wrong RISCV objdump in a post-build step. Instead of riscv64-unknown-elf-objdump, I needed to use riscv64-elf-objdump, which is the one that comes with the RISCV toolchain used by the alire build. It worked locally for me, because I happened to have riscv64-unknown-elf-objdump locally installed and that was hiding the problem. I just updated this PR to fix this problem.
However there are stil some CI builds that fail:

• Windows builds fails, because a post-build step invokes a bash shell script, and bash does not exist on the Windows build machine. Is the a way to say that this crate is not expected to be test-built for Windows?
• Debian-stable and Ubuntu-lts builds fail because the try to build the crate instead of test-building it.

[mosteo]

• Windows builds fails, because a post-build step invokes a bash shell script, and bash does not exist on the Windows build machine. Is the a way to say that this crate is not expected to be test-built for Windows?

If the crate is entirely unavailable on Windows, you can mark it as such using the available property. Otherwise, you can have conditional test actions (e.g., one for Windows that does whatever--or nothing--and another one for the rest of OSes). See the conditional action syntax here looking for "Actions accept dynamic expressions". (I'm afraid TOML syntax is not the most intuitive for this.)

• Debian-stable and Ubuntu-lts builds fail because the try to build the crate instead of test-building it.

I'l take a look into this.

[mosteo]

• Debian-stable and Ubuntu-lts builds fail because the try to build the crate instead of test-building it.

I suspect this is because alr test is using the gprbuild from the distribution, which is failing to find the cross compiler. Our CI setup deals with this when it detects the need in the main crate, but since the script does not really know which crates alr test is going to build, in this case it fails to prepare it.

I see two simple solutions: to add an extra test action before the ones that build that selects the needed gprbuild (alr toolchain --select gprbuild^22) or, probably better, add the dependency on gprbuild^22 to the tests.

[mosteo]

Success! It seems the Windows checks are stuck but after completion. Thanks for the patience and hopefully any updates down the line should be now easy sailing.

[jgrivera67]

Thanks a lot for your help Alejandro

…

On Tue, May 21, 2024 at 11:17 AM Alejandro R Mosteo < ***@***.***> wrote: Success! It seems the Windows checks are stuck but after completion. Thanks for the patience and hopefully any updates down the line should be now easy sailing. — Reply to this email directly, view it on GitHub <#1033 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABEFZMGJXHOQM6GWSS63GVTZDNXSPAVCNFSM6AAAAABGIOHQHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRSHE4DKOBQGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>