Support building with protocol buffers #1544
Merged
Conversation
This file contains 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
cgay
force-pushed
the
protobuf-tool-2
branch
from
f9300c0
to
fc5bf13
Compare
housel
approved these changes
Jan 3, 2024
| // In addition to this code, the compiler executables have to "use protobuf-tool". | ||
|
|
||
| // TODO(cgay): why isn't the tool protocol just an open generic function to | ||
| // which we add a method? |
There was a problem hiding this comment.
Though it wasn't provided, this approach could have allowed introspection so you could do something show tools.
There was a problem hiding this comment.
Makes sense. I'll remove that TODO before merging.
| end | ||
| end function modify-current-project; | ||
|
|
||
| /* Spec file format: |
There was a problem hiding this comment.
Ideally this should go in the documentation rather than be left as a comment in a particular tool.
There was a problem hiding this comment.
I put the documentation in the protocol-buffers repo since we don't have a centralized place for tools in Open Dylan: cgay/protocol-buffers@0b078ed
no semantic changes here
* Remove tabs, trailing whitespace, and do minor reformatting. * Improve command-line arg processing: recognize various cries for help. * Combine module.dylan into library.dylan and remove unnecessary used modules. * Do something useful if the default #"dylan" tool is found. * Use protobuf-tool instead of motley, since the former is what is currently under development. * Add some comments.
The user can either include the generated files into their own library or generate a separate library. The former case is a bit of a hack: * it requires that they use separate files for their library definition and module definition, so that * the generated module definition files (and main code) can be inserted into the project between the first file (assumed to be the user's library definition) and the second file (usually the user's module definition). This way the user modules can use the generated protobuf modules and code. Because of limitations in the build system, tools like protobuf-tool, motley, scepter, et al are only invoked on "user projects". When a project is opened via the registry it becomes a "system project". Therefore, compiling sources/lib/protobuf-tool/tests/pbtool-test-one.lid must be done by passing the .lid file to dylan-compiler directly, and that's why this commit does not include a registry file for pbtool-test-one. When generating a complete library, the user is responsible for creating a registry for the generated library. In this commit, pbtool-test-two-pb is one such registry file. Fixing the build system (or just understanding it better) is future work.
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.
The doc explaining what this implements is here.
Briefly, a new
protobuf-toollibrary that invokes an OD plugin for spec files withOrigin: protobuf.Plus a few minor cleanups.