-
Notifications
You must be signed in to change notification settings - Fork 0
chore(rust): more reusable musl build params #28
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
base: master
Are you sure you want to change the base?
Conversation
ca7768a to
11c58d7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR refactors the Nix build script to make MUSL build parameters more configurable and reusable. It introduces new parameters to support different build targets and hermetic builds.
Key changes:
- Made the build target configurable via a
targetparameter (defaulting tox86_64-unknown-linux-musl) - Added support for hermetic builds through an optional
selfparameter containing git revision info - Conditional logic for git dirty tree checks and ulimit based on whether hermetic builds are enabled
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
I guess can reuse same zig builder env in flake pkg and in non hermetic builds, because you used zig, can hid all complexity behind this thing |
cherryman
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
imo we shouldn't have this in this repo in the first place. if we do anything, it should be an extension to crane that supports building using cargo-zigbuild as we've already somewhat solved. what remains is making minor patches to the upstream project so that it's more compatible with nix
|
you mean we should not mix zigbuild in hermetic and non hermetic builds? crane does only hermetics builds, it does not adops possible strategy to allow for both as needed. |
yeah exactly. it's a bit misleading imo to have a command that says "this will do cross-compilation" but is non-hermetic. it's sort of a hack to begin with. i'd take it out of the repo. we've already worked out a way of having (semi-workable) cross-compilation |
No description provided.