Cross-platform build example

[popatam]

Hi!
Since links from docs are not available, I made some examples for cross-platform wheel build with ci and local https://github.com/popatam/gopy_build_wheel_example (without win yet)

[bjia56]

@popatam Thanks for putting together the example, it was super helpful for me when using gopy to build wheels for multiple platforms! I refined the workflow you had to be able to build on more Python versions for Mac, as well as armv7l (Raspberry Pi) and Windows (though Windows required me to put in a patch on top of gopy 0.4.5) - workflow example here.

Main finding I had when building on Mac was that the Python versions published on python.org consistently failed to link properly. The Python installs that did work were provided by homebrew. Also, for Windows, the SYSTEMROOT environment variable needs to be passed to the gopy subprocess, otherwise Python fails to start due to errors seeding the interpreter random number generator.

[tfuxu]

First off, thanks to both of you for writing these workflows, they make bundling bindings into wheels much easier.

@bjia56 I've been trying to get your setup to work with the bindings I'm currently writing. I've got jobs for Linux x64 and aarch64 working, but I can't get Linux armv7l and Windows x64 to pass through pybindgen installation, because of pip which for some reason can't be found. Here's a workflow log for Windows job, and a log for Linux armv7l job, in this one it looks like pip was found and it supposedly installed pybindgen, but Gopy can't find it anywhere.

Also, there is a MacOS x64 job which fails at importing a library, but this might be fixable with LD_LIBRARY_PATH.

[bjia56]

Hi @tfuxu, some thoughts from my side:

• It's odd that on Windows, cibuildwheel is pulling down a Python version that doesn't have pip installed. You could add a new subprocess.check_call line that runs python -m ensurepip (use sys.executable instead of just the Python in PATH) and see if that resolves the issue.
• For armv7l (and probably all Linux builds), you should use the pip module from the current running Python intepreter (sys.executable). When gopy is invoked, it will use the same Python executable as what is running setup.py. On cibuildwheel, it's possible that their build scripts will symlink the pip in PATH to the pip provided by the current running interpreter, however on my armv7l container there is no such setup and pip (assuming it resolves to /usr/local/bin/pip) is hardcoded to point to 3.8.

fwiw, I haven't tested any of this on gopy 0.4.7 - I have hardcoded my package build to use 0.4.5

[tfuxu]

Alright thanks, I'll try this.

Also, originally I tried using Python from sys.executable on all Linux jobs, but I couldn't get pip to run as a module. Here's a log from master branch where it's still how you have it.

[bjia56]

That might be the same issue as Windows, so I'd recommend trying ensurepip on all platforms

[tfuxu]

ensurepip didn't do a trick, but I was able to finally fix this by switching build frontends to build and adding pybindgen to requires in pyproject.toml.