So. Let's explain a dirty hack. `cbindgen` reads the code and collects
symbols. What symbols do we need? None of the one declared in
`wasm.h`, but for non-standard API, we need to collect all of
them. The problem is that `wasm_named_extern_t` is the only
non-standard type where extra symbols are generated by a macro
(`wasm_declare_boxed_vec!`). If we want those macro-generated symbols
to be collected by `cbindgen`, we need to _expand_ the crate
(i.e. running something like `rustc -- -Zunstable-options
--pretty=expanded`). Expanding code is unstable and available only on
nightly compiler. We _don't want_ to use a nightly compiler only for
that. So how can we help `cbindgen` to _see_ those symbols?
First solution: We write the C code directly in a file, which is then
included in the generated header file with the `cbindgen`
API. Problem, it's super easy to get it outdated, and it makes the
build process more complex.
Second solution: We write those symbols in a custom module, that is
just here for `cbindgen`, never used by our Rust code (otherwise it's
duplicated code), with no particular implementation.
And that's why we have the following `cbindgen_hack` module.
But this module must not be compiled by `rustc`. How to force `rustc`
to ignore a module? With conditional compilation. Because `cbindgen`
does not support conditional compilation, it will always _ignore_ the
`#[cfg]` attribute, and will always read the content of the module.
Sorry.
Remove the `build.rs` hack to add helper functions that are used only
in our tests. Now the tests can use the `tests/wasmer_wasm.h` file,
which simplifies the test workflow: No need to hack the build script
or anything if we want to add a helper function.
It's very similar to `wasm_name_new_from_string` but for
`wasm_byte_vec_t`. It does not make sense to get that in the standard,
but it's very useful when writing tests.
1693: Add `wasmer create-exe` r=MarkMcCaskey a=MarkMcCaskey
This adds the `wasmer create-exe` subcommand. This subcommand is a combination of `wasmer compile --object-file` and linking that compiled Wasm with a main function and libwasmer. Put more plainly: it lets us transform Wasm modules into native executables in one step.
In order for this to work we need:
- [x] Ship wasm.h with Wasmer or use different mechanism to find it
- [x] Ship wasmer_wasm.h with Wasmer
- [x] Requires up to date libwasmer... had to build one and copy it over, may fail in CI because of this... will be fixed with next release though
- [x] More gracefully handle wasmer installed without WASMER_DIR, etc (even if just error messages, should be tested)
- [x] Add tests
# Review
- [ ] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Mark McCaskey <mark@wasmer.io>
Co-authored-by: Mark McCaskey <5770194+MarkMcCaskey@users.noreply.github.com>
When `deprecated` is enabled, the `deprecated` module is included in
the crate.
When `deprecated` is enabled, **only** the `wasmer.h*` header files
will be generated.
When `deprecated` is disabled, **only** the `wasmer_wasm.h` header
file will be generated.
