Skip to content
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

Create Rust-less build for SDK #328

Closed
2 tasks done
pacu opened this issue Dec 2, 2021 · 3 comments
Closed
2 tasks done

Create Rust-less build for SDK #328

pacu opened this issue Dec 2, 2021 · 3 comments
Assignees

Comments

@pacu
Copy link
Contributor

pacu commented Dec 2, 2021

Based on the research done on #311 we want to apply the rustless build approach

Requirements:

  • Repository for the ZcashRustLib or MonoRepo inside the ZcashLightClientKit repo (@pacu and @dh-ecc)
  • ZcashLightClientKit can be distributed over Cocoapods and Swift Package Manager

notes:

  • for rust builds use the cargo.toml on 0.12.0-beta.5
@pacu pacu assigned pacu and dh-ecc and unassigned pacu Dec 3, 2021
@geffenz
Copy link

geffenz commented Jan 12, 2022

Information from duplicate ticket :
What is your feature request?
Currently, building the SDK requires a native Rust build as well. This request is to consider decoupling building the Rust layer from building the SDK layer. The idea would be to have two libraries:

sdk-native-lib which compiles the rust layer and emits an artifact
sdk-lib consumes sdk-native-lib
sdk-native-lib can be published and versioned separately from sdk-lib.

How would this feature help you?
This would significantly simplify and speed up builds of the sdk-lib.

To keep the ability to modify both the sdk-native-lib and sdk-lib at the same time, we can configure a build flag to toggle between the modes of consuming the sdk-native-lib gradle module versus consuming the sdk-native-lib maven artifact

@swansontec
Copy link

Another benefit of the XCFramework approach is that it will finally allow the M1 macs to run this library in the simulator, without Rosetta. This is because an XCFramework allows arm64 iphoneos and arm64 iphonesimulator builds to exist side-by-side, whereas the current vendored_libraries approach does not.

Another problem with the current approach, that this new approach should fix, is that switching back & forth between the x86 simulator and arm64 physical phone requires an rm -rf Pods ; pod install to force-build the static library. Again, the fact that an XCFramework allows multiple builds to exist side-by-side means this should no longer be a problem.

@dh-ecc
Copy link
Contributor

dh-ecc commented Mar 17, 2022

@pacu @geffenz I think this is good to close now with #338 being merged and Electric-Coin-Company/zcash-light-client-ffi#1. I've also added a small PR with a Readme so you don't have to guess how to do things 😅. Electric-Coin-Company/zcash-light-client-ffi#3

@pacu pacu closed this as completed Mar 17, 2022
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

No branches or pull requests

4 participants