Dealing with cross-compilation and Rust dependencies

[marcpabst]

I just saw the excellent work by @freakboy3742 making it possible to run iOS builds using cibuildwheel and maturin. I'm currently using maturin and some shell scripts to build iOS wheels, but being able to build all platforms through cibuildwheel would be very nice.

However, I'm running into a problem where a specific Rust dependency does support building for iOS, but still expects Python (used as a build dependency) to report the host platform. i.e., the Rust crate invokes the build system of a third-party library (in my case, skia), which runs build tasks on the host and is confused when Python reports sys.platform == "ios".

Is there a way to deal with this?

[freakboy3742]

At present, not that I can think of. sys.cross_compiling will return True, which will tell you that sys.platform isn't "real" - but there isn't currently a way to find the platform of the underlying platform.

Out of interest - what package is it that you are compiling, and how much detail of the underlying platform do you need? Is it just sys.platform, or do you need other details (like sysconfig.get_platform()?)

In particular, do you actually need to know the underlying platform, or just that it is "different"? If there's a need to be able to identify the underlying platform, it might make sense to preserve the "original" sys.platform - for example, setting sys.__platform__ to the original value. This would mirror the relationship between sys.stdout and sys.__stdout__.

[marcpabst]

Sorry if I have been unclear. I'm building a PyO3/maturin project throughciebuildwheel. My project depends on skia-safe. So ciebuildwheel calls maturin, maturin calls cargo, cargo runs the build.rs from skia-safe which in turn calls the above Python script as part of the skia build process. Is that the missing link? :)

It's not cibuildwheel's fault, but some libraries will not expect to run in environment where sys.platform in the default Python intepreter returns ios.

[freakboy3742]

Thanks - that's helpful context.

From what I can make out, the problem lies around here - the build command is invoking the python that it has found in the environment; but cibuildwheel is providing the "fake" iOS python.

The current cross-platform environment for iOS doesn't provide a way to "turn off" the cross-platform features. To get the "actual" Python, you'd need to get prerequisites.locate_python3_cmd() to not return the venv's Python - but that's going to be difficult to do that many layers deep in cibuildwheel calls, as it's already going to be manipulating PATH to hide the system python. You might be able to hard code some options here if the target is iOS, but that won't really be a robust solution.

Alternatively, it looks like you might be able to circumvent the download process by putting the skia build into "offline" mode; I don't know how you activate that inside the skia build, but that might provide a window where you can explicitly download the binaries for the build platform and put them somewhere so that skia can invoke them, avoiding the need to autodetect the path for the downloads.

Another approach would be to modify the fetch-gn script so that sys.platform == "ios" is interpreted as a "darwin" set of downloads. That probably won't work if your build machine is x86_64... but from the look of it, that script likely won't work on x86_64 macOS builds, so maybe that's not a concern.

In the (hopefully not too distant) future, I'm hoping to update cibuildwheel to use xbuild - the implementation there does provide a way to "turn off" cross-platform tools, by exporting XBUILD_ENV=off in the environment. That would give you a way to get the build Python without the cross-platform patches.

[freakboy3742]

It's not cibuildwheel's fault, but some libraries will not expect to run in environment where sys.platform in the default Python intepreter returns ios.

Responding to this one specifically - yes, that's true. And that means the code isn't iOS compatible.

However, the same would be true for any other new platform - if I release a new OS that reports sys.platform == "foobar", then the Python ecosystem as a whole needs to be updated to accept that "foobar" is a reasonable and expected response. That's the situation we're in right now with iOS, Android and Emscripten.

Those three platforms add an additional layer of complexity in that they are also cross-compiling platforms, which isn't a situation that Python has historically needed to deal with - and as a result, the ecosystem is needing to come to terms with what that means as well.

[joerick]

I'm not across the specifics, but I wonder if it would be useful for cibuildwheel to add a version of Python to PATH with the name build-python (and build-pip) so that tools can use them? At least then there's a way for build tools to use python if they choose to support cross-compilation?

[freakboy3742]

Having a build-python et al is a technique I've seen used elsewhere (crossenv, does that, for example). However, it's difficult to set up with out a full "build" venv; the XBUILD_ENV=off environment variable option in xbuild is how I've been able to make the approach a lot more practical.

[marcpabst]

In all fairness, that script was never meant to be iOS compatible, as it is only a build dependency and therefore only really needs to know about the platform it's being run on.

But yeah, it's hard to cast blame here. It's not really Skia's fault, as they never intended to build Skia through three layers of tooling. It's not really the fault of skia-safe either, as cargo distinguishes between build and normal dependencies, so everything called from the build.rs file is expected to run on the host (but Python obviously was never part of this equation). It's also not really cibuildwheel's fault, as it can, as you say, hardly account for any potential edge cases three layers deep. So that leavesmaturin. But I think maturin shouldn't really interfere with how dependencies build their dependencies...

I guess the most elegant solution (besides the changes you hinted at xbuild would bring) would be to not depend on the system's Python at all. So skia-safe should provide its own Python interpreter inside a virtual environment. I personally think that in 2025 storage and bandwith is cheap enough to not rely on system-wide dependencies at all, but not sure how universal that opinion is...

For now, I will probably build my own Skia binaries through CI instead of building them through skia-safe. Just that building Skia (like anything Google) is a bit of a pain...