Hi all, I’m pleased to announce that the ROS Cross-Compiler tool has been released to PyPI for the first time!
Like colcon and vcs, ros-cross-compile is a commandline tool that can be installed via pip, which performs work on ROS (or ROS2) workspaces.
This tool builds your ROS workspace for a non-native platform (e.g. arm32 Debian, like is used on the Raspberry Pi) with a single invocation. It works against any workspace that colcon builds, and creates an extra install directory beside your local native-architecture one. You do not have to have any version of ROS installed to use the tool.
Note that this is an early version of the tool. Today, it performs an emulated build rather than a true cross compilation, for example. The intent is to make it trivial, painless, and quick to build your workspace locally on your development machine (or build server) and deploy to your robot, which may be running a different architecture or OS.
Please give it a try, bug reports and feature requests are very appreciated
Interesting use of qemu there – do you have any comparison on how that reduces performance compared to a “true” cross-compile?
btw, we don’t have entirely the same requirements, but micro-ros-build also does cross-compilation. It does it without docker, using a toolchain.cmake. This is mostly painless, except for vendor packages that do not properly pass on the toolchain file to their internal build, but we’re fixing those as we go along (and the android port is also helping).
Apart from that, our main target is RTOS support, so we do a bit more setup stuff, but still, maybe this could be merged at some point…
I unfortunately have no real data, just anecdotally it feels uncomfortably slow compared to cross-compilers / native builds.
It is a big shiny important goal on this tool’s roadmap to go to using cross compilers, which will use cmake toolchains - I still plan to be doing the builds inside docker containers to keep environment/dependency management dead simple, however. The QEMU step was just a way to get out the door quickly and start getting feature requests
vendor packages that do not properly pass on the toolchain file to their internal build, but we’re fixing those as we go along
Yeah, I had to hit a bunch of these vendor packages as well back when we added the libcxx build nightly_linux_clang_libcxx [Jenkins] - but that was mostly making sure to pass the compiler and C/C++ build flags, I’m sure I didn’t get the toolchain everywhere
maybe this could be merged at some point…
Perhaps but it sounds like we’re still trying to support pretty different use cases - we’ll probably discover different issues because of it, which is useful data
Hey all! I wanted to announce a second release of this cross-compile tool! It’s got a lot of quality-of-life improvements in it. Check it out https://pypi.org/project/ros-cross-compile/
Notable improvements
the tool now performs incremental builds - when you change sources it does not need to start from scratch
you can point the tool at any existing colcon workspace, you do not need to manually set up any particular directory structure
added x86_64 as a target architecure - when running on an x86_64 host this provides a “contained build” that manages setup and dependencies without having to install anything on host system
you can provide a colcon defaults file to customize builds
among other little improvements and test coverage increase!
The upcoming plan is to do a small release next with a few minor features, followed by a bigger release supporting true cross-compilation (the build phase is still emulated)
Great to see improvements on this fundamental topic!
I think that besides “true cross-compilation”, the main feature that is missing from this repo (and also from it’s old version) is an easy way for adding new architectures.
That was one of the main goals of the iRobot ROS 2 cross-compilation tool.
This cross-compilation tool is in no way well integrated and easy to use as yours, but at the same time it allows (with minimal pain) to add new supported architectures by using:
a directory containing the sysroot
a compiler
a toolchain
Are there any plans for including a feature like this?
Supporting arbitrary targets is a topic of interest for this tool, but there isn’t a concrete design how it will be handled yet. I have uncertainty about how we gracefully manage rosdep collection for arbitrary sysroots. Regardless, I think this is a nice way to explore after the current planned features are complete.
I think that besides “true cross-compilation”, the main feature that is missing from this repo (and also from it’s old version) is an easy way for adding new architectures.
Thanks for calling out OpenEmbedded, Herb! I think that it is a fantastic set of tools.
The way I see it is that this tool and OpenEmbedded address different use cases. We’re trying to target here the developers who are using out of the box full OS images and want to deploy their code to that, e.g. the average ROS dev that is tossing raspian or Ubuntu MATE on a Raspberry Pi, or is flashing a TX2 with the Nvidia SDK Manager.
Whereas the OpenEmbedded use case serves the more advanced systems developer that has their needs locked down and wants a minimal image for a production device. Correct me if I’m wrong on that assessment, of course.
That’s a fair assessment for a board like the Raspberry Pi where releases of Raspbian and Ubuntu MATE are available for it and well-maintained. For other boards, though, an out of the box full OS may not be available, and OpenEmbedded may be the only option for development of any sort.
but it sounds like we’re still trying to support pretty different use cases - we’ll probably discover different issues because of it, which is useful data