* Use cibuildwheel in ci
`cibuildwheel` is a system that automatically compiles and repairs wheels for
many python versions and architectures at once. This has some advantages vs the
old situation:
- Macosx wheels had inconsistent minimum versions ranging between 10.9 and
11.0. I'm not sure why this happens, but for some users this means they have
to build from source on macosx. With cibuildwheel, the build is
consistent, with 10.9 as the minimum for x86 and 11.0 for arm64.
- Consolidation between the packaging tests and manylinux tests.
- Addition of musllinux targets and additional cross-compilation to ppc64le and
s390x.
- With cibuildwheel, new python versions should be automatically picked up.
- Separation of the sdist build and lint checks. There is not reason to run that
many times.
All possible build targets succeed, except for ARM64 on Windows. The upstream
capnp build fails. I've disabled it.
The cross-compilation builds on linux are pretty slow. This could potentially be
sped up by separating the builds of manylinux and musllinux, but I'm not sure if
it's worth the extra complexity. (One can also contemplate disabling these
targets.)
Tests for macosx arm64 cannot be run (but also couldn't be run in the previous
system. This should be remedied once apple silicon becomes available on the CI.
I've also added some commented-out code that can automatically take care of
uploading a build to PyPi when a release is created. One might contemplate using this.
* Set CMAKE_OSX_ARCHITECTURES for arm64 and disable universal2
* Add Python3.11 to the Github Actions, in the manylinux2014 build as well as the
packaging test.
I added a second image, x86_64, to the manylinux2014 build matrix - the i686
build didn't immediately pass, so I left it out.
* Move the bundled capnproto library forward to 0.10.3.
* Remove the 2010 build entirely, and update the 2014 build to include i686.
The example async server code uses timeouts around read() operations.
However, this has a race condition where data can be read, the timeout
fires, and the data is lost.
These timeouts are not really needed in this example code, so I removed
them to prevent people from having strange issues with lost messages
and undefined RPC behavior when using the example code.
This patch fixes a problem of reading random values for reader options
in pycapnp. The code which adds task to the list captures 'opts' by
reference and that causes a problem in case when 'opts' is allocated on
on the caller's stack. By the time when task is handled the stack frame
holding the 'opts' is gone which leaves dangling reference to 'opts' in
lambda's captures. As a result pycapnp reads random values for reader
options which sometimes causes unexpected errors (for example an error
that nesting level ius negative).
* Fixing issue with m1 build
- prevent earlier build step from running on arm64
- forced clean up of bundled dir
- adding --force-bundled-libcapnp to trigger a rebuild
- echoing out env variables and showing final wheel size
* Disable tests on Apple Silicon cross compile
* Added macos arm64 Apple Silicon to CI
- Added missing python 3.10 metadata to setup.py
* Need all python versions in the matrix
* Fixing github action matrix syntax
* Changing MACOSX_DEPLOYMENT_TARGET for older python versions
- Technically no one would be running python 3.7 on M1 anyway
* Adding windows visualcpp build tools and updated cmake
* Increase max-parallel for all matrix builds
* yaml indent
* trying visualstudio2022-workload-vctools
* disabled everything but windows and added tunshell for debugging
* try older powershell
* trying again
* try python instead of powershell
* bash with wget
* Using old windows client on other side
* wrong way
* backwards
* :(
* urgh back to caveman debugging
- trying older windows runners
* try it again with extra build tools
* Reverting back to windows-2019 runner for windows builds
Fixing error:
CMake Error at CMakeLists.txt:2 (project):
Generator
Ninja
does not support platform specification, but platform
x64
was specified.
There is no test coverage for these exception clauses,
however the invocation of obj.__str__() for client
objects could raise any exception, hence the very broad
exception catch.
