search

bytecodealliance / wasm-micro-runtime

WebAssembly Micro Runtime (WAMR)
Apache License 2.0
4.98k stars 627 forks source link

the purpose of WAMR_BUILD_WASI_TEST #3895

Open Zzzabiyaka opened 2 weeks ago

Zzzabiyaka commented 2 weeks ago

Hi

When i was helping porting WAMR-2.2.0 internally I discovered this build flag WAMR_BUILD_WASI_TEST which only gates this line https://github.com/bytecodealliance/wasm-micro-runtime/blob/e352f0ab101116c46a5a615d5139b70e8e9a3d47/core/iwasm/common/wasm_runtime_common.c#L1363

Hence the question

as we ideally want to build wamr just equally for internal testing and prod, do we need this flag or we can just allow resolving foo by default given that it's used by testsuite?

I see no harm in allowing it by default and simplifying the flow for developers having internal testsuites in addition to ./test_wamr.sh

The problem with that is, on wamr upgrade (we were doing 1.3.1 -> 2.2.0) the very same wasm binaries start failing, which takes dev time to investigate

lum1n0us commented 2 weeks ago

build wamr just equally for internal testing and prod,

It's not always the case. WASM_ENABLE_SPEC_TEST != 0 is used when running a specification test(-s spec), and WASM_ENABLE_WASI_TEST != 0 is for a WASI test(-s wasi_certification). In a production environment, you might choose to disable both.

Using "foo" as a built-in module name is a less robust temporary solution compared to "spectest". It's more likely that someone might have a module they depend on named "foo" as opposed to "spectest". Therefore, setting "foo" as a default built-in module name could lead to more issues. Regarding the WASI test case, WAMR doesn't have an easy method to resolve an imported memory, and WASI certification requires this, so here we are.