Design for new tools for ROS 2 package cross-compilation

[zmichaels11]

Old PR: https://github.com/ros2/design/pull/233

[piraka9011]

@dirk-thomas @pokitoz @nuclearsandwich @filiperinaldi Could you PTAL at this PR and recent updates?

I've updated the article based on your comments in #233. We've also opened a PR in the ros2/cross_compile repo with the requested changes in design doc.

Let us know if there's any updates to make. @prajakta-gokhale and I will address any issues moving forward.

[piraka9011]

@dirk-thomas @pokitoz I've updated the design doc with the requested changes along with some updates based on what we've done so far in the ros2/cross_compile PR.

[dirk-thomas]

Looks good to me - but I don't have much insight into the content so others should "approve" this.

Nitpick: each sentence should start on a new line (following the style guide).

[piraka9011]

If there aren't any other updates/suggestions could we get this merged/closed?

[dirk-thomas]

Maybe someone should review / approve the content? Not sure who would be best for this. I was only looking at the content from a format / terminology point of view.

[piraka9011]

Pinging @pokitoz @alsora and @filiperinaldi to see if they have any suggestions.

[drastx]

A lot of these arm and mips houses that make sbc development or reference boards use openwrt, buildroot or yocto. There are others, but those are the three major ones.

So a lot of the times, developers would have sysroot already built by openwrt or buildroot so being able to use that existing standard mechanism instead of creating specialized docker images would be helpful.

Doing it with docker, you're really hoping that the qemu image matches in terms of libc, special flags, and processor nuances for particular hardware but in reality, I think that will be difficult. The qemu arm support is a bit generalist in my opinion and can be used for platforms that are well supported. But with any new platforms, you're basically limiting your portability because you have to create a specialized docker image yourself. I doubt that any of the SBC houses will invest time doing that.

I used to maintain the tool-chain(compiler,linker,libc, etc...) for a major US-based arm/mips chip manufacturer and personally, I've never seen anyone using docker or qemu for cross-compilation. The approach seems really up the stack for very well supported platforms but not a right solution for hardware bring-up.

So, in my opinion, if you supported standard sysroot options like openwrt and buildroot etc then you are addressing the embedded market better.

In summary, it's ok if you want to use docker/qemu, but that shouldn't be the only supported sysroot. You should be able to point the build to say an openwrt or buildroot sysroot image. My personal feeling is that companies/projects that are doing new hardware support/enablement are more likely to use the openwrt or buildroot, or yocto. And then on the other hand docker approach is going to be used mostly by the audience who's just trying to figure out what this arm thing is... dipping their toes in for like a school project or alike.

[tfoote]

It seems like we've resolved most of the initial issues. There are some additional suggestions/extension points suggested by @drastx above.

I'd suggest that if no one objects we merge this as is in draft state and people can start working on it. And @drastx if you can make any specific suggestions to extend the proposal to add the other sysroots that would be valuable and can be reviewed on top of the current draft.

[thomas-moulard]

@tfoote We have updated the PR, let us know if it's OK and we'll merge it.

[thomas-moulard]

@tfoote Merging as it meets the bar you set.