1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
# CLI Options for `wasmtime`
The `wasmtime` CLI is organized into a few subcommands. If no subcommand is
provided it'll assume `run`, which is to execute a wasm file. The subcommands
supported by `wasmtime` are:
## `help`
This is a general subcommand used to print help information to the terminal. You
can execute any number of the following:
```sh
$ wasmtime help
$ wasmtime --help
$ wasmtime -h
$ wasmtime help run
$ wasmtime run -h
```
When in doubt, try running the `help` command to learn more about functionality!
## `run`
This is the `wasmtime` CLI's main subcommand, and it's also the default if no
other subcommand is provided. The `run` command will execute a WebAssembly
module. This means that the module will be compiled to native code,
instantiated, and then optionally have an export executed.
The `wasmtime` CLI will automatically hook up any WASI-related imported
functionality, but at this time if your module imports anything else it will
fail instantiation.
The `run` command takes one positional argument which is the name of the module
to run:
```sh
$ wasmtime run foo.wasm
$ wasmtime foo.wasm
```
Note that the `wasmtime` CLI can take both a binary WebAssembly file (`*.wasm`)
as well as the text format for WebAssembly (`*.wat`):
```sh
$ wasmtime foo.wat
```
The `run` command accepts an optional `invoke` argument which is the name of
an exported function of the module to run.
```sh
$ wasmtime run foo.wasm --invoke initialize
```
## `serve`
The `serve` subcommand runs a WebAssembly component in the `wasi:http/proxy`
world via the WASI HTTP API, which is available since Wasmtime 18.0.0. The goal
of this world is to support sending and receiving HTTP requests.
The `serve` command takes one positional argument which is the name of the
component to run:
```sh
$ wasmtime serve foo.wasm
```
Furthermore, an address can be specified via:
```sh
$ wasmtime serve --addr=0.0.0.0:8081 foo.wasm
```
At the time of writing, the `wasi:http/proxy` world is still experimental and
requires setup of some `wit` dependencies. For more information, see
the [hello-wasi-http](https://github.com/sunfishcode/hello-wasi-http/) example.
## `wast`
The `wast` command executes a `*.wast` file which is the test format for the
official WebAssembly spec test suite. This subcommand will execute the script
file which has a number of directives supported to instantiate modules, link
tests, etc.
Executing this looks like:
```sh
$ wasmtime wast foo.wast
```
## `config`
This subcommand is used to control and edit local Wasmtime configuration
settings. The primary purpose of this currently is to configure [how Wasmtime's
code caching works](./cli-cache.md). You can create a new configuration file for
you to edit with:
```sh
$ wasmtime config new
```
And that'll print out the path to the file you can edit.
## `compile`
This subcommand is used to Ahead-Of-Time (AOT) compile a WebAssembly module to produce
a "compiled wasm" (.cwasm) file.
The `wasmtime run` subcommand can then be used to run a AOT-compiled WebAssembly module:
```sh
$ wasmtime compile foo.wasm
$ wasmtime foo.cwasm
```
AOT-compiled modules can be run from hosts that are compatible with the target
environment of the AOT-completed module.
## `settings`
This subcommand is used to print the available Cranelift settings for a given target.
When run without options, it will print the settings for the host target and also
display what Cranelift settings are inferred for the host:
```sh
$ wasmtime settings
```
|
