update texts

This commit is contained in:
bytedream 2024-09-29 18:16:01 +02:00
parent 8db02f2e36
commit da63980914
3 changed files with 8 additions and 9 deletions

View File

@ -15,7 +15,7 @@ pub extern "C" fn lua_new() -> *mut mlua::Lua {
Alright, good. Alright, good.
Now we have a Lua instance, but no way to use it, so let us create one. Now we have a Lua instance, but no way to use it, so let us create one.
<br> <br>
The function takes the pointer to the Lua struct we create in the `new_lua` function as well as an arbitrary string, which should be lua code, as parameters. The function takes the pointer to the Lua struct we create in the `new_lua` function, as well as an arbitrary string, which should be lua code, as parameters.
It then executes this string via the Lua instance and may write to `stderr` if an error occurs. It then executes this string via the Lua instance and may write to `stderr` if an error occurs.
```rust,ignore ```rust,ignore
#[no_mangle] #[no_mangle]

View File

@ -58,7 +58,7 @@ const module = {
stderr.appendChild(line); stderr.appendChild(line);
} }
}; };
// this loads the wasm file and exposes the `ccall` and `cwrap` functions whic we'll // this loads the wasm file and exposes the `ccall` and `cwrap` functions which we'll
// use in the following code // use in the following code
const myProject = await wasm.default(module); const myProject = await wasm.default(module);
``` ```
@ -156,7 +156,7 @@ class MyProject {
#stdout; #stdout;
#stderr; #stderr;
static async init(): Promise<MyProject> { static async init() {
const myProject = new MyProject(); const myProject = new MyProject();
const wasm = await import('./target/wasm32-unknown-emscripten/debug/my-project.js'); const wasm = await import('./target/wasm32-unknown-emscripten/debug/my-project.js');

View File

@ -2,15 +2,15 @@
## Create the project package ## Create the project package
First, you need to create a normal Rust package. First, you need to create a normal Rust package which can either be a binary or library crate.
This can either be a binary or library crate, they are working nearly the same. A binary crate has a main function that will be executed when initializing the main function, a library crate needs a few more additional compiler flags to compile successfully.
As binary: As binary:
```shell ```shell
cargo init --bin my-package . cargo init --bin my-package .
``` ```
As library As library:
```shell ```shell
cargo init --lib my-package . cargo init --lib my-package .
``` ```
@ -45,14 +45,14 @@ mlua = { version = ">=0.9.3", features = ["lua51", "vendored"] }
### `build.rs` ### `build.rs`
You need to set some additional compiler options to be able to call your wasm code from Javascript: You need to set some additional compiler flags to be able to call your wasm code from Javascript:
- `-sEXPORTED_RUNTIME_METHODS=['cwrap','ccall']`: this exports the `cwrap` and `ccall` Javascript functions which allows us to call our library methods - `-sEXPORTED_RUNTIME_METHODS=['cwrap','ccall']`: this exports the `cwrap` and `ccall` Javascript functions which allows us to call our library methods
- `-sEXPORT_ES6=1`: this makes the created js glue ES6 compatible. It is not mandatory in general but needed as this tutorial/examples utilizes ES6 imports - `-sEXPORT_ES6=1`: this makes the created js glue ES6 compatible. It is not mandatory in general but needed as this tutorial/examples utilizes ES6 imports
- `-sERROR_ON_UNDEFINED_SYMBOLS=0` (_optional for binary crates_): this ignores undefined symbols. Typically undefined symbols are not really undefined but the linker just can't find them, which is always the case if your crate is a library - `-sERROR_ON_UNDEFINED_SYMBOLS=0` (_optional for binary crates_): this ignores undefined symbols. Typically undefined symbols are not really undefined but the linker just can't find them, which is always the case if your crate is a library
> If your package is a library, you have to add some additional options: > If your package is a library, you have to add some additional options:
> - `--no-entry`: this defines that the compiled wasm has no main function > - `--no-entry`: this defines that the compiled wasm has no main function
> - `-o<library name>.js`: by default, only a `.wasm` file is created, but some js glue is needed to call the built wasm file (and the wasm file needs some functions of the glue too). This creates the glue `<library name>.js` file and changes the name of the wasm output file to `<library name>.wasm`. This must be removed when running tests because it changes the output filename and the Rust test suite can't track this > - `-o<library name>.js`: by default, only a `.wasm` file is created, but some js glue is needed to call the built wasm file (and the wasm file needs some functions of the glue too). This creates the glue `<library name>.js` file and changes the name of the wasm output file to `<library name>.wasm`. This must be removed when running tests because it changes the output filename and the Rust test suite can't track this.
The best way to do this is by specifying the args in a `build.rs` file which guarantees that they are set when compiling: The best way to do this is by specifying the args in a `build.rs` file which guarantees that they are set when compiling:
```rust,ignore ```rust,ignore
@ -70,7 +70,6 @@ fn main() {
> // the output files should be placed in the "root" build directory (e.g. > // the output files should be placed in the "root" build directory (e.g.
> // target/wasm32-unknown-emscripten/debug) but there is no env variable which > // target/wasm32-unknown-emscripten/debug) but there is no env variable which
> // provides this path, so it must be extracted this way > // provides this path, so it must be extracted this way
>
> let target_path = std::path::PathBuf::from(out_dir) > let target_path = std::path::PathBuf::from(out_dir)
> .parent() > .parent()
> .unwrap() > .unwrap()