add --component-type and --string-encoding options
#32
Conversation
Per bytecodealliance/wit-bindgen#994, this allows all or part of the component type to be specified as one or more WIT files rather than binary-encoded custom sections. This is akin to inserting a `wasm-tools component embed` command between the linking and componentization stages. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
src/lib.rs
Outdated
| if resolve.worlds.len() != 1 { | ||
| bail!( | ||
| "expected exactly 1 world in {wit_file:?}; found {}", | ||
| resolve.worlds.len() | ||
| ); | ||
| } |
There was a problem hiding this comment.
I'm hesitant about this as I'm afraid that worlds will sneak in pretty quickly. Could this perhaps stick to the "path plus --world" combo of other tools? That way this could use Resolve::select_world. It would preclude multiple --component-type arguments, however, so that would only work if that's ok for your use case.
There was a problem hiding this comment.
That would be difficult for two reasons:
- The goal is to be able to check this WIT file into source control and pass it to
wasm-component-ldas easily as we were previously passing_component_type.ofiles, with no further information needed. Not sure where the world name would be stored. - There will definitely be more than one of these files in general. At least one will be bundled as part of the .NET runtime, and another coming from any bindings generated by the application developer (plus any which are part of SDKs that application is using).
There was a problem hiding this comment.
Perhaps we should reconsider using WIT (as opposed to e.g. WAT) for this? With WAT there isn't any notion of worlds -- just top-level imports and exports, so all the questions about which world (and which string encoding?) go away.
There was a problem hiding this comment.
Or else: stick with WIT but ensure that wit-bindgen only ever emits exactly one world -- the one it was provided as input (i.e. flatten any include statements that refer to other worlds).
There was a problem hiding this comment.
Joel and I talked more about this and the conclusion was:
- The general structure here will stay except that
select_worldwill be used to provide some more future flexibility. - The generated
*.witfile in the bindgen generators will be generated differently to work with this.
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
|
I've updated the code here to use |
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Signed-off-by: Joel Dice <joel.dice@fermyon.com>
Per bytecodealliance/wit-bindgen#994, this allows all or part of the component type to be specified as one or more WIT files rather than binary-encoded custom sections. This is akin to inserting a
wasm-tools component embedcommand between the linking and componentization stages.