When compiling `wasmer-runtime-c-api` as a dependency of another
crate, `rustc` emits this warning:
```
warning: The package `wasmer_runtime_c_api` provides no linkable
target. The compiler might raise an error while compiling
`foo`. Consider adding 'dylib' or 'rlib' to key `crate-type` in
`wasmer_runtime_c_api`'s Cargo.toml. This warning might turn into a
hard error in the future.
```
To solve this issue, the `rlib` type has been added to the
`crate-type` list.
This patch removes the `WASM_EMSCRIPTEN_GENERATE_C_API_HEADERS`
flag. Consequently, the C header files will be generated for each
build.
The `generate-c-api-headers` feature is also removed, since it becomes useless.
This patch changes the directory where the C header files are
generated, from `CARGO_MANIFEST_DIR` to `OUT_DIR`. The goal is: When
`wasm-runtime-c-api` is used as a dependency of another Rust project,
then the C header files are accessible in the `target/` directory
(i.e. the `OUT_DIR`).
Also, since `rustc` has a `--out-dir` directory, it increases the
flexibility of this approach: The user can generate the C header files
where she wants.
When requiring `wasmer-runtime-c-api`, I get the following conflicts:
```
error: failed to select a version for `serde_derive`.
... required by package `cbindgen v0.7.1`
... which is depended on by `wasmer-runtime-c-api v0.2.1`
... which is depended on by `foo v0.1.0 (/private/tmp/foo)`
versions that meet the requirements `= 1.0.58` are: 1.0.58
all possible versions conflict with previously selected packages.
previously selected package `serde_derive v1.0.89`
... which is depended on by `wasmer-runtime-core v0.2.1`
... which is depended on by `wasmer-runtime-c-api v0.2.1`
... which is depended on by `foo v0.1.0 (/private/tmp/foo)`
failed to select a version for `serde_derive` which could resolve this conflict
```
This issue resolves by updating `cbindgen` to 0.8.
This patch cleans several warnings where mutable bindings are declared
but used only as immutable bindings.
It's a little bit opinionated patch. I think it's interesting to use
`const` pointers as much as possible.
This patch removes `unsafe { … }` blocks inside `unsafe` functions.
This patch also removes some warnings about camel case. All structures
with a C representation are automatically not mangle, and allow non
camel case.
* Change RuntimeError type and fix codebase to use it
* Fix spectests to work with new runtime error type
* Fix windows signal handler in the clif-backend
* Add missing conversion
* final windows fix
* remove exception handler when function returns or throws
* revert to only reserving and not committing memory due to issues
* appveyor builds for release, caches more, only publish artifact once
I was looking into the code and I noticed that this option is not used.
The `debug!` macro is used across the codebase, which looks more ideal.
Signed-off-by: David Calavera <david.calavera@gmail.com>
notes:
I could have used the -e flag in echo, however other lines
nearby use printf so I figured it would be smart to stay consistent.
Also, I see the usage of `command printf`. Not 100% if this is
necessary. I don't see why printf would be redefined in the shell.
If we're doing this, then we might as well prefix every call
to a builtin or binary with `command` _just to be safe_.
