macos-cross-compiler
repairwheel
macos-cross-compiler | repairwheel | |
---|---|---|
4 | 3 | |
324 | 27 | |
- | - | |
8.8 | 8.1 | |
3 months ago | 3 months ago | |
Earthly | Python | |
GNU General Public License v3.0 only | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
macos-cross-compiler
-
I stopped worrying and loved Makefiles
Make is excellent if you use it properly to model your dependencies. This works really well for languages like C/C++, but I think Make really struggles with languages like Go, JavaScript, and Python or when your using a large combination of technologies.
I've found Earthly [0] to be the _perfect_ tool to replace Make. It's a familiar syntax (combination of Dockerfiles + Makefiles). Every target is run in an isolated Docker container, and each target can copy files from other targets. This allows Earthly to perform caching and parallelization for free, and in addition you get lots of safety with containerization. I've been using Earthly for a couple of years now and I love it.
Some things I've built with it:
* At work [1], we use it to build Docker images for E2E testing. This includes building a Go project, our mkdocs documentation, our Vue UI, and a ton of little scripts all over the place for generating documentation, release notes, dependency information (like the licenses of our deps), etc.
* I used it to create my macOS cross compiler project [2].
* A project for playing a collaborative game of Pokemon on Discord [3]
IMO Makefiles are great if you have a few small targets. If you're looking at more than >50 lines, if your project uses many languages, or you need to run targets in a Docker container, then Earthly is a great choice.
[0]: https://earthly.dev/
[1]: https://p3m.dev/
[2]: https://github.com/shepherdjerred/macos-cross-compiler
[3]: https://github.com/shepherdjerred/discord-plays-pokemon
-
Show HN: dockerc – Docker image to static executable "compiler"
It will depend heavily on the docker image you're trying to ship. For example with macos-cross-compiler[0] the resulting binary is over 2GB. With python:alpine[1] it's only 25MB.
Because image isn't copied whether the image is 2GB or 25MB the startup time will be nearly instantaneous for both.
The runtime adds 6-7MB of overhead although I expect that this can be reduced to less than 3MB with some work.
[0]: https://github.com/shepherdjerred/macos-cross-compiler
- So You Want to Ship a Command-Line Tool for macOS
- Show HN: macOS-cross-compiler – Compile binaries for macOS on Linux
repairwheel
-
Ask HN: What rabbit hole(s) did you dive into recently?
I got into cross-compiling Python wheels (e.g., building macos wheels on linux and vice versa). Zig's `zig cc` does much of the heavy lifting, but one step in building a portable wheel is the "repair" process which vends native library dependencies into the wheel, necessitating binary patching (auditwheel does this for linux, delocate for macos).
I wanted to be able to do this cross platform, so I re-implemented ELF patching and Mach-O patching and adhoc signing in Python, and wrapped them into a tool called repairwheel: https://github.com/jvolkman/repairwheel
-
Show HN: macOS-cross-compiler – Compile binaries for macOS on Linux
I'll plug some work I've been doing to (attempt to) enable cross compilation of Python wheels. I put together a small example [1] that builds the zstandard wheel, and can build macos wheels on linux and linux wheels on macos using zig cc.
macos wheels must still be adhoc signed (codesign) and binary patched (install_name_tool), so I re-implemented those functions in Python [2].
[1] https://github.com/jvolkman/bazel-pycross-zstandard-example
[2] https://github.com/jvolkman/repairwheel/tree/main/src/repair...
-
Sunday Daily Thread: What's everyone working on this week?
I mixed auditwheel, delocate, and delvewheel into a single tool called repairwheel and reimplemented all of the required external tools (patchelf, otool, codesign, etc.) in pure python.
What are some alternatives?
dockerc - container image to single executable compiler
tensorflow-windows-wheel - Tensorflow prebuilt binary for Windows
enroot - A simple yet powerful tool to turn traditional container/OS images into unprivileged sandboxes.
cibuildwheel - 🎡 Build Python wheels for all the platforms with minimal configuration.
dockcross - Cross compiling toolchains in Docker images
twine - Utilities for interacting with PyPI
py2exe - Create standalone Windows programs from Python code