feat: C++ bindings for protobuf#7590
Closed
aakoshh wants to merge 3 commits into7511-compare-program-serfrom
Closed
feat: C++ bindings for protobuf#7590aakoshh wants to merge 3 commits into7511-compare-program-serfrom
aakoshh wants to merge 3 commits into7511-compare-program-serfrom
Conversation
Contributor
Author
|
@TomAFrench do you agree that we close this and do it in |
Member
|
Hey, yeah I agree that once we have the proto file then we can leave it up to aztec-packages to generate their bindings. |
5 tasks
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.
Description
Problem*
Part of #7511
Builds on #7513
Summary*
Generates C++ bindings for the Protobuf schemas, to be used by Barretenberg.
I originally thought this would be convenient since we already have the
acir.cppandwitness.cppfiles generated, which contain the models necessary to deserialise thebincodeencodedProgramandWitnessMap, and at this point we already haveprotocwhich we can invoke right there in the same step, always keeping the two in sync.On second thought, this is probably best left to be done on the
aztec-packagesside: as long as the.protoschemas are available to that build, we can decide there which ones need to be built, and also make sure they compile (ie. that we have not forgotten anything, because unlikeprost,protoconly generates source for what we tell it to do explicitly). It is also more conceptually sound because then the consumer decides what bindings to generate, rather we having to know exactly whatbbcan ignore (that is, we don't generate C++program.protoandbrillig.proto).I'm opening the PR for the record, but I think we should close it and wait until we have synced the schemas over to
aztec-packagesand do it there.We still have to generate
acir.cppandwitness.cppon the Noir side because it works with reflection, and inaztec-packagesour job is to update e.g.acir.hpp, generate fresh Protobuf mappings, then manually do the mapping between them whenever something changes that we want to use on that side.Additional Context
Documentation*
Check one:
PR Checklist*
cargo fmton default settings.