Open
Conversation
This adds two new features: - Multiple `--world` options are accepted, in which case the worlds will be merged into a single world for building, testing, or bindings generation. - In addition to any worlds and/or WIT paths specified explicitly via CLI options, `componentize-go` will use `go list` to scan the current module and its dependencies, looking for files named `componentize-go.toml` in their source trees. For each such file found, any worlds and/or WIT paths referenced therein will be added to the respective lists. This behavior can be disabled using the `--ignore-toml-files` option if desired. In combination, these options make it easier to use multiple SDKs or other libraries which contain `wit-bindgen-go`-generated code. Note that I've also removed the `wat` dependency because `go build` always generates a binary Wasm file, so no need to check for or parse WAT. Fixes bytecodealliance#28
…via CLI Previously, we'd union all the worlds specifiec via the CLI _and_ via `componentize-go.toml` files, but that can get very confusing for the user. Now we'll only use the toml file ones as a default if none are specified via the CLI.
This was only used for the build subcommand, but all subcommands potentially need to know where the go module is e.g. to locate `componentize-go.toml` files, so we should either promote it to be a subcommand-independent option or drop it and require that `componentize-go` be run in the directory containing the module of interest. I chose the latter in this case, but we could certainly revisit that.
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
1 participant
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.
This was only used for the build subcommand, but all subcommands potentially
need to know where the go module is e.g. to locate
componentize-go.tomlfiles,so we should either promote it to be a subcommand-independent option or drop it
and require that
componentize-gobe run in the directory containing the moduleof interest. I chose the latter in this case, but we could certainly revisit
that.
Note that this builds on #35 and shouldn't be merged until that one is merged.