On 7/1/19 1:10 PM, Sebastian Kuzminsky wrote: > On 7/1/19 11:55 AM, andy pugh wrote: >> On Mon, 1 Jul 2019 at 17:09, Sebastian Kuzminsky >> <seb.kuzmin...@gmail.com> wrote: >> >>>> Also when I look at this page >>>> http://buildbot.linuxcnc.org/dists/stretch/ >>>> <http://buildbot.linuxcnc.org/dists/stretch/> it shows master and 2.7 >>>> haven’t been updated since 09-Jun >>> >>> Oops! Fixed, thanks for letting me know. >> >> Any plans for a Buster Buildbot? > > I'd very much like to add Buster builders to the Buildbot. > > LinuxCNC builds on Buster and the tests pass, so run-in-place style > build-and-test should be doable today. > > But some parts of LinuxCNC have runtime dependencies that are not > available in Buster. We'd have to figure out what to do about those > parts before we can start shipping Buster debs... > > >> Is it worth looking at cross-compiling for armhf if native arm boards >> are not reliable enough? >> (It's not particularly useful for build process testing, but having >> the debs would at least get some users testing) > > I'd much rather do native arm builds, both because of the test coverage > issue you mentioned and also to keep the build process unified across > hardware architectures. > > As Seb points out, there are good reasons to use native builds, and testing is the most compelling to me. The new RPi 4 [1] is pre-shipping in a $55 version with 4GB RAM, and would be easy to add to a BuildBot, or if you're thinking of migrating that BuildBot out of your shop, consider Scaleway's cheap, bare-metal ARM-architecture cloud [2]. These two options are well-suited for both building and testing.
In case anyone's still interested in cross-compiling, I have a lot of relevant experience with Machinekit; read on. If not, stop reading right here! Cross-building still has an advantage even when testing on ARM architecture is a requirement. Packages can be quickly built on more powerful arm64 hardware (cross-builds are as fast as native builds), and native-architecture tests can be run on e.g. BeagleBone, a platform targeted to run (IIRC) but anemic to build LCNC. However, cross-compiling Debian packages for ARM is non-trivial. The `Multi-Arch:` header in `debian/control` is the future solution for cross-building packages, but even though this has been around for several Debian distros, it's still not implemented properly in all packages. The last time I really dug down into this, in Stretch, Multiarch support was broken in some of the Machinekit build dependencies. Cross-build support in LCNC needs to be added to the packaging, to `configure.ac` and to the build system. Doing this for Machinekit took me a few days. Once it's done, it would be worth looking at whether LCNC Buster packages can be cross-built with Multiarch. It's possible that LCNC deps are just enough different from MK's and that Buster Multiarch support has improved enough since Stretch that this will work. It's easy to test, and if successful, cross-building packages would be completely painless. For the Machinekit project, I wanted to cross-build in Travis CI's amd64 cloud instances. I devised a solution that installs ARM-architecture dependencies in a chroot-like filesystem under `/sysroot/` using `multistrap`, adds some monkey patches, and uses `gcc --sysroot=/sysroot` to cross-build packages. This is all done in Docker images to make it easy to build this ugly, messy build environment on Docker Hub or my laptop, and use it to cross-build anywhere. Take a look at the the base image [3] and the companion build script [4] if you're curious. IMO it's an amazing hack (at least for its hairiness), but at the same time an abomination that I hope will soon be obviated by progress in the Multiarch project. John [1]: https://www.raspberrypi.org/products/raspberry-pi-4-model-b/ [2]: https://www.scaleway.com/en/arm-instances/ [3]: https://github.com/zultron/mk-cross-builder [4]: https://github.com/machinekit/machinekit/blob/master/scripts/build_docker _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers