Open tqwewe opened 10 months ago
Could you provide the build error you're encountering?
The guest project is missing the package metadata that marks it as a component project; currently cargo-component
does not attempt to componentize just any wasm
target outputs.
If you add [package.metadata.component]
to your guest's Cargo.toml
, does that workaround the issue?
Could you provide the build error you're encountering?
Ah sorry I forgot to add this :facepalm: I get an error from wasmtime loading the wasm module:
thread 'main' panicked at host/src/main.rs:27:92:
called `Result::unwrap()` on an `Err` value: failed to parse WebAssembly module
Caused by:
attempted to parse a wasm module with a component parser
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
If you add
[package.metadata.component]
to your guest'sCargo.toml
, does that workaround the issue?
It does! However, would cargo component be willing to change this behaviour and add the component metadata no matter if the [package.metadata.component]
is present?
The reason being is that:
cargo component build
, then they'd definitely have the intention of building it as a wasm component.I'm building a runtime which uses wasmtime, and users of my runtime will compile their modules as cargo components. However telling them that they need to add an empty [package.metadata.component]
to get it working, despite them already using cargo component is just one extra gotchya that seems not too necessary?
Ideally, they could just use cargo new
, and then add crate-type = ["cdylib"]
, and my macro thalo::export_aggregate!(Foo)
and it should work with cargo component build
Why wouldn't they use cargo component new
which sets both the crate-type
and adds the required [package.metadata.component]
section? As a bonus, it also gives them the opportunity to configure different cargo component values with arguments (e.g. package name, editor, vcs).
Alternatively, they could just use a template you create so you can embed your thalo
macro call for them.
Why wouldn't they use
cargo component new
It would indeed be nice, however it also generates the wit directory, and adds cargo-component-rust to the dependencies, etc. These things aren't needed in my case. I don't want them to be concerned with wit files or anything like that, as my library handles it all.
Alternatively, they could just use a template you create so you can embed your thalo macro call for them.
Also a nice idea, but I wanted to keep things as simple as possible for them. So it's just a regular rust crate, and they need thalo
as a dependency. The only complicated thing would be that they need to add the crate-type, but that's just a rust thing with wasm.
As I mentioned, isn't it a little strange to have the behaviour of the cargo component build
silently not generate a wasm component if the meta is not defined?
If someone uses the cargo component build
command then I'd say it's safe to assume they're definitely expecting the resulting wasm to be a valid wasm component
@tqwewe
With cargo-component
0.9.0, it now componentizes any core module that has bindings type information present (where previously it required [package.metadata.component]
to be present in Cargo.toml
for it to componentize).
Please review the release notes as there were quite a few breaking changes relating to bindings in that release.
Description
There's an inconsistency when building a project with inline WIT definitions using
cargo component build
. It fails undercargo component
but succeeds when manually building withcargo
andwasm-tools
withwit-bindgen
given the followinglib.rs
:Reproduction Steps
Manual Build with Cargo and wasm-tools
wasm32-wasi
target:Hello, World!
message:Build with Cargo Component
cargo component
:Expected Behavior
Both build methods should successfully compile and run the project, displaying
Hello, World!
regardless if we use awit
directory withcargo_component_bindings
orwit-bindgen
.Actual Behavior
The build succeeds with manual steps but fails with
cargo component
.Additional Information
Repository Link: GitHub Repository
Is this intended behaviour? I think it would be ideal if we can just use cargo component with wit-bindgen as an easy way of building wasm components, though it seems like we need to stick to the structure of having a
wit
directory along side oursrc
directory.