cc (Jan 23 2024 at 22:07): cc (Jan 23 2024 at 22:07):I am using the wasmtime c api in a cpp project. I want to support linking a component-model component (using the wasmtime bindgen macro with a wit file). Is there a way from rust to get a handle to the *void data attribute on the store data? The generated component model linking code passes the data attribute (of type StoreData) from the store context directly, so I can't use wasmtime_context_get_data.
Alex Crichton (Jan 23 2024 at 22:14):It sounds like you're augmenting the C API and/or adding your own functions, is that right? If that's so then the theory is "do what the implementation of wasmtime_context_get_data does" which may mean that StoreData needs to grow some APIs to access the private pointer
cc (Jan 23 2024 at 22:20):that makes sense to me. whats the process for proposing and implementing this sort of change? should I create an issue?
Alex Crichton (Jan 23 2024 at 22:22):an issue works but if you're able to send a PR that would be best!
cc (Jan 23 2024 at 22:23):I also need to unwrap the wasmtime_linker_t to the underlying rust Linker<> - would a helper function make sense to add to the api?
Alex Crichton (Jan 23 2024 at 22:30):sure!
Pat Hickey (Jan 24 2024 at 00:00):just want to call out that wasmtime::Linker is exposed as wasmtime_linker_t, but wasmtime::component::Linker is a distinct type and is not yet in the C API, there is some ongoing work on that by @Tyler Rockwood here https://github.com/bytecodealliance/wasmtime/pull/7801
cc (Jan 24 2024 at 01:13):thanks for sharing that and pointing out the different linker types. i'll follow along with that pr.
Tyler Rockwood (Jan 24 2024 at 02:30):Just FYI please feel free to jump in with component model and the C API if someone has cycles, I will probably be moving slowly to implement this, starting by improving the C API testing story.
Last updated: Nov 22 2024 at 16:03 UTC