When I tried the previous `arm64` wheel on macOS, I discovered that `pip` on macOS only supports the `arm64` platform tag in a limited set of circumstances. pip seems to prefer `universal2` wheels.
To build a `universal2` wheel, we must run the `llvm-lipo` tool to bundle multiple `cc_binary()` outputs into a single output wheel. We use a transition to depend on multiple architectures for the extension, if we see that we are building for a multiarch CPU.
PiperOrigin-RevId: 447486256
While I've made some progress debugging b/231485326, I'm not going to be able to get this fully working in time for -rc1.
If I can debug this before the final release, we can re-enable the win32 wheels.
PiperOrigin-RevId: 446849335
This should get us the full set of binary wheels we need for release. Also added acceptance tests for all wheels except aarch64 (on Linux and macos): we cannot test these without emulation, which will require a somewhat more complicated setup.
PiperOrigin-RevId: 446574958
1. For some reason the version script was not working, it was failing to export the main symbol for the Python extension. I fixed this by using the `visibility` attribute instead to export the `PyInit__message` function.
2. We were not properly stripping the `python/dist/` prefix for the C module, which was making the module exported under the name `dist.google._upb` instead of `google._upb`.
3. The `py_library()` rule was failing to actually propagate the module file into the wheel, so I just removed it.
PiperOrigin-RevId: 445446611
This creates a multi-job workflow. The first step builds all wheels, using the Docker image and cross-compiler. The second step attempts to install that wheel on all platforms.
Future changes will enhance this workflow to also install and run the tests. We also need to add macOS wheels, which are not currently being built.
PiperOrigin-RevId: 444952832
An enum MiniDescriptor simply encodes a set of valid `int32_t` values, so that the protobuf parser can test whether a given enum value is known or not.
The format implemented here is novel and needs to be documented. In short, the format is:
1. base92 values 0-31: 5-bit mask indicating presence or absence of the next five enum values.
2. base92 values 60-91: varint indicating skip over a region of enum values.
Negative enum values are encoded as their `uint32_t` equivalent.
PiperOrigin-RevId: 442892799
From now on, these files will live in the "generated" branch only, and a GitHub action will regenerate these files whenever there is a commit to the main branch.
PiperOrigin-RevId: 438879338