On a high level, this is what this PR changed:
1. Move the CLI chapter before the API chapter.
I think this makes sense because the CLI is more high-level.
The same change was proposed in
https://github.com/bytecodealliance/wasmtime/pull/7987.
1. Move some Rust and C examples from the "Examples" chapter into the API chapter.
1. Remove the original main C and Rust chapter introduction files.
They contained mostly outdated or duplicate information.
1. Rename the "Examples" chapter to "Further Examples".
(For lack of a better name.)
1. Rename "Embedding" to "API" at some places since API is a more generally known term.
The term "embedding" is also slightly more confusing, I think,
because the term nowadays also used a lot in LLM-related communication.
1. Read through the entire document and fix some outdated links and information.
1. Fix a missing subheading for Elixir (it was mentioned on the lang page, but not in the menu).
* Clarify some wasm terms in the introduction
* Update docs/introduction.md
* Update docs/introduction.md
---------
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
* Add a "custom" platform configuration for Wasmtime
This commit leverages adds a new "platform" to Wasmtime to be supported
in the `crates/runtime/src/sys` folder. This joins preexisting platforms
such as Unix and Windows. The goal of this platform is to be an opt-in
way to build Wasmtime for targets that don't have a predefined way to
run.
The new "custom" platform requires `--cfg wasmtime_custom_platform` to
be passed to the Rust compiler, for example by using `RUSTFLAGS`. This
new platform bottoms out in a C API that is intended to be small and
Linux-like. The C API is effectively the interface to virtual memory
that Wasmtime requires. This C API is also available as a header file at
`examples/min-platform/embedding/wasmtime-platform.h` (generated by
`cbindgen`).
The main purpose of this is to make it easier to experiment with porting
Wasmtime to new platforms. By decoupling a platform implementation from
Wasmtime itself it should be possible to run these experiments
out-of-tree. An example of this I've been working on is getting
Wasmtime running on bare-metal with a custom kernel. This support
enables defining the platform interface of the custom kernel's syscalls
outside of Wasmtime.
* Exclude wasmtime-platform.h from formatting
* Include build-wasmtime-target-wasm32 in final job
* Don't force any single toolchain
* Add notes to no_std docs
* Add rust-src to CI
* Review comments
* Change APIs to be fallible
* Only compile the min-platform example on Linux
* Fix compile of min-platform example
* Fix another compile error in the example
* WIP: try to make wasi-common self contained.
* rebase: cargo.lock
* remove all dependencies between wasi-common and wasmtime-wasi
* use wasi-common directly throughout tests, benches, examples, cli run
* wasi-threads: use wasi-common's maybe_exit_on_error in spawned thread
not a very modular design, but at this point wasi-common and
wasi-threads are forever wed
* fix wasmtime's docs
* re-introduce wasmtime-wasi's exports of wasi-common definitions behind deprecated
* factor out determining i32 process exit code
and remove libc dep because rustix provides the same constant
* commands/run: inline the logic about aborting on trap
since this is the sole place in the codebase its used
* Add high-level summary to wasi-common's top-level doc comment.
* c-api: fix use of wasi_cap_std_sync => wasi_common::sync, wasmtime_wasi => wasi_common
* fix tokio example
* think better of combining downcast and masking into one method
* fix references to wasmtime_wasi in docs
prtest:full
* benches: use wasi-common
* cfg-if around use of rustix::process because that doesnt exist on windows
* wasi-common: include tests, caught by verify-publish
* fix another bench
* exit requires wasmtime dep. caught by verify-publish.
* Move `jit` crate to `environ`
Move the platform agnostic parts of the crate `wasmtime-jit` to
`wasmtime-environ`. This is the first part of the refactoring discussed
here: https://github.com/bytecodealliance/wasmtime/issues/7652 and a
follow up will move the remaining parts of `wasmtime-jit` so that the
crate can be deleted.
* Move `jit` crate to `wasmtime`
Move the remaining parts of `wasmtime-jit` to the `wasmtime` crate and
remove `wasmtime-jit`. This is part of the refactoring discussed in
https://github.com/bytecodealliance/wasmtime/issues/7652.
* undo toml formatting
* Trigger pipeline: prtest:full
* Remove `jit` directory
* move `ProfilingAgent` out of `profiling` feature
* add links to ELF_NAME_DATA
I realized just now that we haven't actually documented our usage of
`cargo vet` anywhere in our contributing documentation (or not that I
could find), so I decided to try and rectify that!
* Expand further minimization section of documentation
This commit fills out the page about producing minimal builds a bit
more. The intention here is to provide examples of ideas about how to
reduce size further as well as current limitations and how they can be
evaluated.
* Review comments
* riscv64: Extend distance trampolines can jump
Use a PIC-friendly set of instructions to enable destination of the
trampoline to be more than 4k away from the tail call site of the
trampoline itself.
* Build "min" artifacts on CI
This commit updates the binary artifacts produced by CI to include "min"
builds where all default features are disabled. Additionally all the
stops are pulled in terms of build flags, nightly versions, etc, to get
a build that is as small as possible without actual source code changes.
This effectively codifies the instructions in #7282 into an easily
downloadable artifact.
No new tarballs are created for github releases but instead tarballs
that previously had a `wasmtime` executable for example now have a
`wasmtime-min` executable. Furthermore the C API which previously had
`libwasmtime.so` for example now has `libwasmtime-min.so`. The intention
is that the minimum-size artifacts are handy for determining a rough
size of Wasmtime but they're not so important that it seems worthwhile
to dedicate entire release entries for.
CI is refactored to support these minimum builds with separate builders.
This means that a single tarball produced as a final result is actually
two separate tarballs merged together, one for the normal build we do
today plus a new "min" tarball produced on the new "min" builders.
Various scripts and CI organization has been adjusted accordingly.
While here I went ahead and enabled `panic=abort` and debuginfo
stripping in our current release artifacts. While this doesn't affect a
whole lot it's less to upload to GitHub Actions all the time.
* Fix Windows unzip
This commit changes the `--dir` argument on the `wasmtime` CLI to be
`HOST::GUEST` rather than `GUEST::HOST`. This matches Docker for example
and is a little more consistent with only `--dir path` where the first
argument is always treated as a host directory.
In terms of breaking-ness the movement from `--mapdir` to `--dir` hasn't
been released with Wasmtime 14 yet so my hope is that this can land on
both `main` and Wasmtime 14.0.0 before it's released to avoid any
breakage other than existing scripts migrating from `--mapdir` to
`--dir`.
* Move `wasmtime explore` behind a Cargo feature
Enable this Cargo feature by default, but enable building the CLI
without the `explore` subcommand.
* Move the `wast` subcommand behind a Cargo feature
* Move support for `wat` behind a CLI feature
This was already conditional in crates such as `wasmtime` and this makes
it an optional dependency of the CLI as well.
* Move CLI cache support behind a Cargo feature
Additionally refactor `wasmtime-cli-flags` to not unconditionally pull
in caching support by removing its `default` feature and appropriately
enabling it from the CLI.
* Move `rayon` behind an optional feature
* Move `http-body-util` dependency behind `serve` feature
* Add a Cargo feature for compiling out log statements
This sets the static features of `log` and `tracing` to statically
remove all log statements from the binary to cut down on binary size.
* Move logging support behind a Cargo feature
Enables statically removing logging support in addition to the previous
compiling out log statements themselves.
* Move demangling support behind a Cargo feature
* Enable building the CLI without cranelift
Compile out the `compile` subcommand for example.
* Gate all profiling support behind one feature flag
This commit moves vtune/jitdump support behind a single `profiling`
feature flag that additionally includes the guest profiler dependencies
now too.
* Move support for core dumps behind a feature flag
* Move addr2line behind a feature
* Fix rebase
* Document cargo features and a minimal build
* Tidy up the source a bit
* Rename compile-out-logging
* Document disabling logging
* Note the host architecture as well
* Fix tests
* Fix tests
* Mention debuginfo stripping
* Fix CI configuration for checking features
* Fix book tests
* Update lock file after rebase
* Enable coredump feature by default