alexcrichton commented on issue #5214:
Thanks for the PR!
Personally though I'm hesitant to merge this because I don't think that this is how the C API is best used. If you're writing Rust code and linking to Wasmtime it's recommended to use the
wasmtime
crate embedding API rather than the C API (as it's possible to be 100% safe). If you're instead using the C API then that's typically done through some precompiled artifact meaning you probably don't want Cargo to build the C API at the same time as your embedding's build.Given that I'm not sure how useful this would be. Adding the
lib
crate type has unfortunate size implications on the resulting artifact (weird rustc internal things) so it's something I'd prefer to avoid.Could you perhaps explain more how you're envisioning integrating the C API into your embedding? Is there a reason you're specifically avoiding the
wasmtime
crate's API?
psarna commented on issue #5214:
Thanks for more context! My use case is quite specific as the project is going to slowly migrate to more and more Rust code, so compiling our own limited C API is a temporary measure, which would just make it more ergonomic to mix C base with just the minimal subset of Wasmtime's API that we need. I'm absolutely fine with this patch not landing upstream though, I'll just maintain it on a fork until it's no longer needed.
P.S. the resulting library was 17MiB, so pretty much the same as the prebuilt, so perhaps the size amplification isn't that bad? In any case, I'll just close this pr and continue with a thin fork, since indeed my use case is rather obscure. Thanks!
alexcrichton commented on issue #5214:
Ah I think my knowledge may be dated at this point, the issue I'd seen in the past seems no longer present. Still though if you're ok with a fork for now I think that would be good. If it becomes problematic over time though feel free to let us know.
Last updated: Nov 22 2024 at 16:03 UTC