Skip to content

Conversation

@dzmitry-lahoda
Copy link
Contributor

No description provided.

@dzmitry-lahoda dzmitry-lahoda force-pushed the dz/4 branch 2 times, most recently from ca7768a to 11c58d7 Compare October 27, 2025 17:30
Copy link

Copilot AI left a 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 target parameter (defaulting to x86_64-unknown-linux-musl)
  • Added support for hermetic builds through an optional self parameter 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.

@dzmitry-lahoda
Copy link
Contributor Author

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

Copy link
Contributor

@cherryman cherryman left a 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

@dzmitry-lahoda
Copy link
Contributor Author

dzmitry-lahoda commented Oct 31, 2025

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.

@cherryman
Copy link
Contributor

you mean we should not mix zigbuild in hermetic and non hermetic builds?

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

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.

3 participants