[WIP] Enable true cross compilation workflow

[emersonknapp]

Fixes #69

This branch is in no clean state for review, but is tracking the progress of a cross-compilation workflow.

It currently works OK - but runs into problems with some include/linker paths when building various workspaces. This might be a deficiency of the workflow, or of the CMake packages being used - TBD.

If there are outstanding deficiencies in source packages that make them difficult to cross-compile against, we may want to continue to provide the emulated build option, as it will work as well as native as far as paths are concerned.

[TSC21]

@emersonknapp really great job on cross_compile and what it allows!

Is there any progress in this PR though? Emulation builds take a gigantic amount of time and consume too much CI resources (for automated builds), so this would be great to revive and bring in. Thanks in advance!

[TSC21]

@emersonknapp can you provide a quick guidance on how this can be rebooted? there's a lot of interest on getting this work done. If you don't have the time, can you instead provide some guidelines on what needs to be completed and fixed? Thanks in advance!

[emersonknapp]

Thanks for the ping - this project unfortunately got de-prioritized on my side so I have not had time to spend on it.

I've just rebased on the latest master, so the diff is more understandable (though I don't know if the code works now).

I can identify the following ways to help make progress here

1. Test this branch for yourself and see if it works. Fix anything that doesn't and contribute it to this branch.
2. This PR started as a big wishlist of parts - it does too many things all at once. Identify individual fixes/improvements/rearchitectures from this branch and pull them out into small, focused, provable PRs that get us closer to the end goal state

The end goal of this PR is to be able to cross-compile build a ROS workspace against Debian/Ubuntu. If you have a good sample workspace of interest to you, that would be an awesome test case. I personally have been using the workspace described in https://github.com/emersonknapp/robo/blob/master/ros/homey.repos - which runs the gamut of ROS 2 application parts - C++, Python, navigation, SLAM, etc. Lots of good stuff in there. Being able to build that to produce an Ubuntu aarch64 build is my "holy grail" outcome.

After that, we can then consider designs for even more expanded use cases - if desired.

[TSC21]

Ok I already started fixing some things based on the fixed from running the tests on tox. I'll let you know how it goes.

[TSC21]

@emersonknapp I have already pushed some fixes to https://github.com/TSC21/cross_compile/tree/cross-compile. This is as far as I could go so far - the cross-compilation process gets stuck forever in copying the sysroot. I do see the sysroot files being updated, but it's incrementally increasing the size of it and it really takes a long time (without a clear understanding when is it going to stop).

INFO:Docker Client:Successfully tagged ros_cross_compile/x86_64-ubuntu-foxy:sysroot
INFO:ros_cross_compile.sysroot_creator:Successfully created sysroot docker image: ros_cross_compile/x86_64-ubuntu-foxy:sysroot
INFO:ros_cross_compile.sysroot_creator:Exporting sysroot
INFO:ros_cross_compile.sysroot_creator:Extracting sysroot to destination

Can you have a look at the branch and suggest what needs to be changed there? Thanks!

[TSC21]

@emersonknapp any input on the above? Thanks in advance!

[TSC21]

@christophebedard @lucashan any chance you can provide some input on the above? Thanks in advance!

[christophebedard]

@TSC21 unfortunately I don't know much about this project so I couldn't say.

[emersonknapp]

the cross-compilation process gets stuck forever in copying the sysroot.

Is it actually stuck forever or does it just take a long time? Good to know. I'm not sure - given the DockerPy interface, whether we can get feedback on this export. It may be worth skipping the Python API and shelling out directly to Docker, though I don't think that gives progress feedback either. Also, if you can try the command manually to see how long it takes from the Docker CLI, that's good input as well. If the Python version is significantly longer, then no reason to do that, we might as well call a subprocess. This was a first-pass attempt at a complex sequence of steps, I've done no performance analysis on any given part.

[MichaelOrlov]

• Closing this PR a stale and wouldn't be merged since we are going to archive cross_compile repo. Feel free to reopen it if you think it would be possible to prepare it to be merged in one week time frame.