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

feat(compile): compile w/dependencies and options #965

Merged
merged 6 commits into from
Mar 9, 2023

Conversation

kobyhallx
Copy link
Contributor

@kobyhallx kobyhallx commented Mar 8, 2023

Related issue(s)

#952 Allow compilation with dependencies from WASM, #888 (comment)

Resolves #952 Allow compilation with dependencies from WASM

Description

Allows to call compile with a set of dependencies as a second argument. Those dependencies will be later resolved from noir-lang/noir-source-resolver

Summary of changes

crates/wasm/src/lib.rs adds the additional argument which will be iterated over to resolves dependencies. It's equivalent to declaring it in project configuration.

Note: Usage example is demonstrated here
https://github.com/noir-lang/noir-cra/blob/master/src/compile_prove_verify.js#L50

Dependency additions / changes

noirc_driver is now required by wasm

Test additions / changes

N/A

Checklist

  • I have tested the changes locally.
  • I have formatted the changes with Prettier and/or cargo fmt with default settings.
  • I have linked this PR to the issue(s) that it resolves.
  • I have reviewed the changes on GitHub, line by line.
  • I have ensured all changes are covered in the description.

Documentation needs

  • This PR requires documentation updates when merged.

Additional context

crates/wasm/src/lib.rs Show resolved Hide resolved
crates/wasm/src/lib.rs Outdated Show resolved Hide resolved
@kobyhallx kobyhallx requested a review from jfecher March 8, 2023 19:35
jfecher
jfecher previously approved these changes Mar 8, 2023
TomAFrench
TomAFrench previously approved these changes Mar 8, 2023
Copy link
Member

@TomAFrench TomAFrench left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a huge fan of the multiple return value types (single program vs an array of programs) but I don't think it's a blocker.

@kobyhallx
Copy link
Contributor Author

kobyhallx commented Mar 9, 2023

I'm not a huge fan of the multiple return value types (single program vs an array of programs) but I don't think it's a blocker.

What's the alternative you're thinking about?

Perhaps having overloaded method?

I was going for party with CLI first.

@kobyhallx kobyhallx dismissed stale reviews from TomAFrench and jfecher via 2c158f9 March 9, 2023 10:26
@TomAFrench
Copy link
Member

What's the alternative you're thinking about?

My preference is to have separated logic for compiling contracts vs single programs which is then reusable here.
i.e. nargo compile determines whether you want a contract or program, call the relevant function which returns the compiled artifacts (either single or vector) and then writes these to disk. We then reuse the middle step in this crate.

I was going for party with CLI first.

Yep, it matching our implementation in the CLI is why I'm fine with this going through. We can refactor later as we define the compilation code-paths for programs/contracts more.

That said I think that having multiple "return types" is a bit different when writing to the FS rather than passing values back to code.

@kobyhallx
Copy link
Contributor Author

What's the alternative you're thinking about?

My preference is to have separated logic for compiling contracts vs single programs which is then reusable here. i.e. nargo compile determines whether you want a contract or program, call the relevant function which returns the compiled artifacts (either single or vector) and then writes these to disk. We then reuse the middle step in this crate.

I was going for party with CLI first.

Yep, it matching our implementation in the CLI is why I'm fine with this going through. We can refactor later as we define the compilation code-paths for programs/contracts more.

That said I think that having multiple "return types" is a bit different when writing to the FS rather than passing values back to code.

Agreed, this is still WIP to be addressed.

@kobyhallx kobyhallx closed this Mar 9, 2023
auto-merge was automatically disabled March 9, 2023 11:11

Pull request was closed

@kobyhallx kobyhallx reopened this Mar 9, 2023
@kobyhallx kobyhallx enabled auto-merge March 9, 2023 11:12
@kobyhallx kobyhallx added this pull request to the merge queue Mar 9, 2023
Merged via the queue into master with commit 3f897f6 Mar 9, 2023
@kobyhallx kobyhallx deleted the kh-compile-dep-wasm branch March 9, 2023 12:01
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.

Allow compilation with dependencies from WASM
3 participants