You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently if we include mopro-core as an external dependency and try to run cargo build we get:
Compiling mopro-core v0.1.0 (https://github.com/oskarth/mopro.git#67382964)
The following warnings were emitted during compilation:
warning: mopro-core@0.1.0: BUILD_CONFIG_PATH not set. Using default configuration.
error: failed to run custom build command for `mopro-core v0.1.0 (https://github.com/oskarth/mopro.git#67382964)`
Caused by:
process didn't exit successfully: `/Users/user/repos/github.com/oskarth/mopro/mopro-cli-example/target/debug/build/mopro-core-5e7bbc90bb897fab/build-script-build` (exit status: 101)
--- stdout
cargo:warning=BUILD_CONFIG_PATH not set. Using default configuration.
--- stderr
thread 'main' panicked at /Users/user/.cargo/git/checkouts/mopro-471ecc433f4d4aff/6738296/mopro-core/build.rs:96:5:
Make sure the zkey file exists. Did you forget to run a trusted setup? Adjust prepare.sh if necessary.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
This is less than ideal because it breaks a common default workflow.
Notes
Using a config.toml file gets rid of this, but it shouldn't necessarily be a requirement for building whole project.
The default fallback is relative to mopro-core example circuits. Not clear how to deal with this in external dependency.
Can we have some other kind of fallback? Or get rid of that build complexity altogether somehow?
Strictly not necessary as we can just say "don't use cargo build", but would be nice to address.
Acceptance criteria
Make default cargo build work without additional work from user when including mopro as a dependency.
The text was updated successfully, but these errors were encountered:
And instead bubble up to run time, or compile time of user application. So if you try to run init on circuit that doesn't have arkzkey etc you get a panic with instruction to prepare this material. That way default cargo build would work.
(Also this is mopro semantics, so perhaps it is mopro build that should fail, not cargo build)
Problem
Currently if we include mopro-core as an external dependency and try to run
cargo build
we get:This is less than ideal because it breaks a common default workflow.
Notes
Using a config.toml file gets rid of this, but it shouldn't necessarily be a requirement for building whole project.
The default fallback is relative to mopro-core example circuits. Not clear how to deal with this in external dependency.
Can we have some other kind of fallback? Or get rid of that build complexity altogether somehow?
Strictly not necessary as we can just say "don't use cargo build", but would be nice to address.
Acceptance criteria
Make default
cargo build
work without additional work from user when including mopro as a dependency.The text was updated successfully, but these errors were encountered: