feat: multi system #4
Conversation
fix: solana-cli build w/ crossbeam-epoch
|
Amazing @Karrq looking forward to trying your version. I didn't quite get my branch working. |
deps(platform-tools): partial 1.43 support
fix(anchor): avoid calling +nightly on bundled cargo
fix(flake): don't package anchor 0.30.1 directly fix(anchor): 0.30.1 full patch feat: passthru.otherVersions
There was a problem hiding this comment.
Thanks @Karrq for the PR and the work. This is a clear improvement to support multi systems and allow flake access so its easier to get started with a single command
Unfortunately I don't really have the expertise to maintain this due to unfamiliarity with crane and not having access to a Mac system to know if it'll break at a future point in time
If you'd like to maintain this as a fork, I'd be happy to link to your fork in the README file as superseding this repo for mac/multi system instead of just x86 linux.
Alternatively we'll need to setup some ci/github actions to make sure it'll remain functional across all systems
pkgs.nix
Outdated
| solana-platform-tools = | ||
| self.callPackage (import ./solana-platform-tools.nix) {}; |
There was a problem hiding this comment.
in flake.nix, there's a custom crane override for these. Is that not needed here?
There was a problem hiding this comment.
crane is just a way for nix to orchestrate the build for rust crates, but in this case platform-tools is just a set of binaries as we don't built them from source in the derivation, hence why it's not needed.
I'll investigate this, I agree that would be ideal, and also allow the project to ensure it works in other platforms without having to test it manually |
style(anchor-cli): formatting
chore: cleanup niv sources
|
Alright, I formatted the codebase with the rfc formatter, unified all inputs (to be managed by flakes), made sure that the current interface (shell, pkgs) is supported, and added a CI workflow that should check that the tools at least build properly. I think to actually see the workflow running I'd need to add it to |
arijoon
left a comment
arijoon
left a comment
There was a problem hiding this comment.
Thanks we can merge to master and see it in action, its mainly for the future updates to make sure other systems don't break. Just need to change the workflows to run on master instead of main
|
Ok, I will keep an eye out and make a followup PR with eventual fixes if necessary. |
|
Unfortunately the current system does not work due to this solana-foundation/anchor#3663 |
|
I've tried to address it here: 4746896 I managed to get a working build on Linux, given the toolchain hasn't changed, I'm hoping it works on mac too, but I couldn't find a way without giving anchor the nightly build. Really wish rust projects would stop depending on unstable features, this seems like an abuse of nightly channel when its meant to try new features, not include them in stable software |
3 participants
Hello! I'm a mac user and wanted to make use of your derivations to manage my solana install.
Unfortunately, it seemed like there was no support for mac at the time, but looking at the forks it seems like @0xPlish was working on a multi-system derivation, also making use of flakes.
For me it @0xPlish's work wasn't building properly, in my case
crossbeam-epoch(forsolana-cli) wasn't able to build due tono_atomic.rsbeing a symlink to a file outside the crate root (in the repo root), thus the source wasn't available forbuildRustPackage.I tried multiple ways to override the dependendy but couldn't figure it out, so in the end I switched to
cranewhich handled the build out of the box.Then I had an issue with
anchor-cli, where the unpatched sources were used to build the dependencies of the binary (as part of a caching step, due to crane's build methodology) and thus the resulting binary had erroneous behaviour.I also excluded the stripping of rlib files since rustc was unable to compile libcore (among others) without those.
Finally, I expanded the
systemMappinginsolana-platform-toolsto also hold the output hashes.