Repository navigation
Dnix - #90
Merged
Merged
Dnix#90
Conversation
added 11 commits
October 22, 2026 00:23
…Nix otherwise The build hook is dnix's. By default it downloads the library of the release dnix.lock names and verifies its hash; in source mode it builds the same library with Nix and verifies the same hash; in dev mode it builds with Nix for work on the Rust code. dnix.json names the library, the asset, the Rust workspace and crate, the Rust and Xcode versions, the deployment floors, and ten targets; dnix.lock records what the source builds to and names release native-8164512a97c6. The flake hands dnix the configuration, along with cmake for RandomX, a static libc++ on Android, and the hash of the randomx crate's checkout, whose RandomX submodule Nix's own fetcher cannot reach. Two crates move to branches that build this way. epic_core kept the foundation JSON outside its own directory, which a vendored crate does not have, so the cypherstack/epic branch vendorable-foundation-json keeps a copy inside the crate. randomx-rust master compiled RandomX for the machine doing the build; the branch reproducible-cross-builds builds the same bytes everywhere, cross-compiles to the MSVC target, and links the C++ runtime per target, so Android no longer needs libc++_shared.so shipped beside the library. There is no Windows library: RandomX's C++ build assumes Microsoft's compiler and assembler, which the sandbox's clang-cl and llvm-ml do not accept. The previous workflow built it with Visual Studio on a Windows runner. OpenSSL is vendored only where native-tls links it, Linux and Android. The prebuilt manifest, the source fingerprint, and their tests and tools go; two-line tools update the lock and verify one platform against the release.
…lock dnix's reusable workflow builds the library on Linux x86_64, Linux aarch64, macOS with Xcode 27.0, and Linux inside WSL2 on Windows, rebuilds each sandboxed target, compares every host with every other and with the committed lock, and on main publishes the release the lock names if it does not exist yet. Runs on main are never cancelled, since one may be publishing. The test workflow runs the Flutter tests on Linux and macOS, against the prebuilt library once its release exists and from source before that, checks the generated bindings, builds the example for macOS and the iOS simulator, and runs the Rust unit tests, as before. The per-platform release builds went with the pipeline they served, and the Windows test host with the Windows library.
How the hook obtains the library and the three modes, how a change to the Rust code becomes a lock entry and a release, how anyone rebuilds a platform and compares, and why there is no Windows library yet.
The library gains x86_64-pc-windows-gnullvm, built with zig's MinGW-w64 through dnix. RandomX's build assumes Microsoft's compiler and assembler on the MSVC side, which no other host provides, while its GCC-style build works unchanged, so the GNU ABI is what Windows gets. The DLL links its runtime pieces statically and imports only system DLLs; an MSVC-built Flutter application loads it like any other. There is no arm64 Windows library: winapi 0.2 in the dependency tree defines its types for x86 only. dnix moves to the commit that supports the GNU targets and what this crate's build script needs of them: CMake driven by the cmake crate, bindgen, and the windows crate's synchronization import library. The tests workflow gains a Windows job that runs flutter test with the prebuilt library once the lock's release is published, the first place the Windows DLL is loaded rather than compared by hash.
The randomx-rust branch now carries only what these targets need: RandomX keeps its default architecture on Apple arm64, and Android links the NDK's libc++ statically. The MSVC changes it also carried are gone, since RandomX's MSVC build cannot work here and Windows builds for the GNU ABI, which needs none of them. So is the narrowing to RandomX's library alone: CMake builds its default target again, test programs included, as master does. The epic commit's message changed, not its files. Every library hashes as before, so dnix.lock and the release it names stay as they are.
The README's ABI section had lost its fence and appeared twice, and it claimed the Windows DLL loads in an application before anything had loaded it. It now lists windows among the platforms verify_release rebuilds and tells applications to drop the user defines the old hook read. The CHANGELOG describes the dnix build instead of the manifests it replaced. The arm64 Linux test job could never start, since subosito/flutter-action finds no arm64 Flutter release for Linux, and main never ran Flutter there. .gitattributes gives the reason its LF rules still matter, and the ignored prebuilt and patches directories went with the tools that made them.
Flutter 3.47 asks every native asset for iOS 13, whatever the application's deployment target, and writes 13.0 into the framework it wraps the library in, so with the floor at 15 dnix's hook refused every iOS build of an application using this package. main built iOS 15 into a framework that said 13.0. Only the three iOS libraries change bytes, so the lock names release native-fd015b3bc09c.
slopbot9k/dnix 57efe93, the stable-sort branch, not yet on cypherstack: build-time dependencies are resolved alike on every build host, rustc sorts the same everywhere, bindgen gets fixed headers, and a target keeps only its dynamic library. Only the x86_64 Android library changes: randomx's bindings are now generated against the NDK's headers on every host, where macOS used Xcode's. The new lock matches what Linux x64, Linux arm64, and macOS each build.
epic_core now embeds its foundation tables only behind a feature that nothing here enables, so its vendored copy needs no JSON beside the source. The patched epic crates follow cypherstack/epic's optional-embedded-foundation branch. Every target was rebuilt; the lock names the new release.
The epic and randomx-rust pull requests landed as merge commits on fix/randomx-v0.2.0-api and master, so the patch lines now name those branches, as main does, and the lock pins the merge commits. The branch name is part of cargo's metadata hash, so every library changed and dnix.lock names a new release.
sneurlax
approved these changes
Oct 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.