Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build macOS architectures separately for CI and wheels #2702

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

swt2c
Copy link
Collaborator

@swt2c swt2c commented Feb 9, 2025

Building the architectures separately allows them to be built in parallel, which will speed up CI but also result in smaller wheels which should be more efficient instead of universal wheels.

@swt2c swt2c force-pushed the macos_build_arches_separately branch from 6ce928a to 646effb Compare February 9, 2025 23:23
@echoix
Copy link
Contributor

echoix commented Feb 9, 2025

I was exploring at the end of this afternoon to see how easy it would be to use cibuildwheel to use a standardized environment (standardized in the sense that it is common to lots of big and widely used packages).

I can't conclude anything for now

@swt2c
Copy link
Collaborator Author

swt2c commented Feb 10, 2025

I was exploring at the end of this afternoon to see how easy it would be to use cibuildwheel to use a standardized environment (standardized in the sense that it is common to lots of big and widely used packages).

I can't conclude anything for now

I think we'd need to get pyproject.toml builds working completely, though, right? When I've used cibuildwheel in other projects, I believe it expects to be able to use build, which doesn't work currently.

@echoix
Copy link
Contributor

echoix commented Feb 10, 2025

I was exploring at the end of this afternoon to see how easy it would be to use cibuildwheel to use a standardized environment (standardized in the sense that it is common to lots of big and widely used packages).
I can't conclude anything for now

I think we'd need to get pyproject.toml builds working completely, though, right? When I've used cibuildwheel in other projects, I believe it expects to be able to use build, which doesn't work currently.

Maybe... and the build is problematic, as normally everyone would use python -m build, but we need to have the repo's root on path, and we have a file named build that gets called instead of the tool...

Building the architectures separately allows them to be built in
parallel, which will speed up CI but also result in smaller wheels which
should be more efficient instead of universal wheels.
@swt2c swt2c force-pushed the macos_build_arches_separately branch from 646effb to af41c7e Compare February 10, 2025 00:46
@swt2c
Copy link
Collaborator Author

swt2c commented Feb 10, 2025

I was exploring at the end of this afternoon to see how easy it would be to use cibuildwheel to use a standardized environment (standardized in the sense that it is common to lots of big and widely used packages).
I can't conclude anything for now

I think we'd need to get pyproject.toml builds working completely, though, right? When I've used cibuildwheel in other projects, I believe it expects to be able to use build, which doesn't work currently.

Maybe... and the build is problematic, as normally everyone would use python -m build, but we need to have the repo's root on path, and we have a file named build that gets called instead of the tool...

Yep, I ran into those same problems too (and didn't solve them). ;-)

@echoix
Copy link
Contributor

echoix commented Feb 10, 2025

Maybe... and the build is problematic, as normally everyone would use python -m build, but we need to have the repo's root on path, and we have a file named build that gets called instead of the tool...

Yep, I ran into those same problems too (and didn't solve them). ;-)

At least when doing it out of cibw, build also provides a cli script pyproject-build, that doesn't conflict too much. Or I used uv, with uv build/uv build --sdist/uv build --wheel.

When building on arm64 this causes wxWidgets to be built as x86_64.
Instead we just want to build the native arch by default.
@swt2c swt2c force-pushed the macos_build_arches_separately branch from af41c7e to 323520f Compare February 10, 2025 01:58
@swt2c swt2c marked this pull request as draft February 10, 2025 02:31
@swt2c swt2c force-pushed the macos_build_arches_separately branch from 074dcf7 to c7ba27f Compare February 11, 2025 03:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants