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
