As mentioned in Snapcraft Office Hours #2-2017-07-07, cross compiling for go plugin has been well supported. still there is a great need to support Python plugin
Hence as @kalikiana suggested, I open this post for discussion on the progress and the testing of cross-compiling support for python plugin.
I did some research and found distutilscross which seems to make setup.py aware of cross-compilation if a few environment variables point it to the desired configuration. So far so good.
Unfortunately installing python3-dev for a target architecture, eg. python3-dev:armhf, conflicts with native packages. I’ve seen this happen with glib2.0-dev before, but in this case it’s worse because it affects non-development packages as well and in the attempt I removed snapd among other important things. This seems like a no-go because it’s unusable on a desktop machine.
I’m going to look into downloading Python binaries separately to avoid this problem.
Hey, I’ve made a Docker image for cross-compiling any unsupported snap on the armhf architecture. I’m using it routinely to build my node.js based snaps, which require native compilation and do not offer native snapcraft cross-compile support.
You’ll find the instructions here: https://github.com/dawidcrivelli/snapcraft_armhf . The readme supposes you have your sources in a src subfolder, but that’s very easily changed. Just use change the line
docker run -d --rm -v $PWD/build/armhf:/build snaparm sh -c "snapcraft clean && snapcraft"
to
docker run -d --rm -v ANY_ABSOLUTE_PATH:/build snaparm sh -c "snapcraft clean && snapcraft
You’ll find the compiled _armhf.snap file in the path you specified
Now I’d like to move to snapcraft 3.x
Does someone has experience to do cross-compilation to armhf with snapcraft 3.x. @dawid did you already experiment with that? Thanks
There are no plans, sorry. If someone wants to contribute a very robust implementation which can deal with C-bindings we might consider it. In the meantime, snapcraft remote-build (available on 3.9.1 on the candidate channel) is the next best alternative for public projects
Yo, it’s me, the necromancer, digging around in the archives again.
I was gonna take a look at that docker image, but I also wanted to poke y’all about Python cross compilation support again. Why does it not support cross-compilation? Is it just problems with package conflicts? Has anybody picked this up again?