GCC toolchain declaration shouldn't use global platforms

[vedranMv]

Hi,

I think I bumped into an issue regarding toolchain - platform compatibility. Namely, in toolchains/gcc_arm_none_eabi/gcc_arm_none_toolchain.bzl there's defined a list of allowed architectures which, among other options, contains armv8-m.base that I'm currently using in my project.

This option is not available in bazel's platforms so once toolchain resolution comes to "@platforms//cpu:" + architecture, it breaks.

An alternative would probably be to use "//constraints/cpu:" + architecture, so that it uses CPUs defined in workspace which can then be used both when declaring platforms, and devices (used by toolchains).

My setup works with that approach, but I'm not sure if it could have undesired consequences elsewhere. What do you think about that?

[nathaniel-brough]

Using global platforms prevents fragmentation in the ecosystem. For example, if I define my own constraints in this repository. But then someone downstream uses this repository and then uses a select in the cpu definition in bazel/platforms you end up in an inconsistent state between your toolchains and selects. e.g. you could end up in a scenario where your toolchain is selected for a cortex-m0 but your selectable dependencies are chosen to match against a cortex-m4.

For some background. I have run some ideas past the Bazel team there are some constraints that they are unlikely to support e.g. fpu, coprocessor etc. Which is fine and is why I created the experimental bazel-embedded/embedded-platforms repository. But if there is already a constraint_setting upstream that serves your needs we should use that.

In an ideal situation, that CPU definition 'armv8-m' should just be upstreamed to bazel/platforms. Then it should be updated in this repository to match. I'd be happy to accept a PR here that does just that. I don't think that there would be any reason the bazel-team would reject such a change upstream either.

An alternative would probably be to use "//constraints/cpu:" + architecture, so that it uses CPUs defined in workspace which can then be used both when declaring platforms, and devices (used by toolchains).

I'm not a huge fan of this approach as it would essentially force an incompatibility between all users of bazel-embedded.

Regardless I agree that armv8-m support should be added!

I don't have the time to tackle this at the moment as I need to prioritise paid work. But here is how I think this should be done.

1. fork bazel/platforms
2. add armv8-m to your fork
3. fork bazel-embedded
4. add armv8-m to your fork
5. in your project change git_repository(...., remote = "https//github.com/your/bazel_embedded_fork") and git_repository(...., remote = "https//github.com/your/platform_fork")
6. Test that everything is working correctly
7. Open PR's both here and in bazel/platforms

Once the upstream bazel/platforms fork goes through I'd be happy to accept a PR here.

[nathaniel-brough]

Feel free to reach out here if you have any further queries along the way. If you need help/guidance along the way I'll do my best to answer questions here.

[vedranMv]

Thank you for sharing your thoughts on this. I'm pretty new to bazel, but I'll try to look into it in the coming weeks

[nathaniel-brough]

Not a problem, feel free to open a pull request early, just call it something like "WIP: Adds armv8-m support", that way you can tag me in a comment if you need any guidance.