Try to enhance no std support

[Sieluna]

Currently, only loading module through file uses std. We can consider excluding this part to make lib support no-std.

[Sieluna]

A new entrance for builder, make import module with variant names easier.

[Sieluna]

@lum1n0us Can you give me some suggestions? I think this proposal would be helpful.

[lum1n0us]

Love it. We might rebase this after PR #102 has been merged.

---

I thought the idea was about creating the smallest possible program without using the standard library, but it appears to be going in a different direction. Am I wrong?

[Sieluna]

I thought the idea was about creating the smallest possible program without using the standard library, but it appears to be going in a different direction. Am I wrong?

I think what I've done aligns with the principles advocated by Rust. However, it was inspired by this discussion:
https://stackoverflow.com/questions/57611219/when-adding-no-std-to-a-library-are-there-any-disadvantages-or-complicati

[lum1n0us]

Library users certainly don't need to worry. If a library enables no_std, its users are not required to enable no_std as well. The compiler will manage it appropriately.

Using no_std is definitely a challenge for library developers, since core is a subset of the std crate. Without access to alloc and advanced features (like Vec and String), developers face many limitations in programming. However, libraries also gain strong compatibility and cross-platform capabilities by using no_std.

[AlixANNERAUD]

Any updates ?

[Sieluna]

Any updates ?

Actually, I was thinking we could completely use something like embedded-io to handle file streams. But this involves considerable changes, and I’m not sure whether it’s necessary to proceed.

[AlixANNERAUD]

Why not disable such feature because WAMR can works without files when using your own abstraction layer (not the one included within WAMR) or disabling such features. Only create alloc is required in the end.

[Sieluna]

Why not disable such feature because WAMR can works without files when using your own abstraction layer (not the one included within WAMR) or disabling such features. Only create alloc is required in the end.

This is already the case, there is no file system related code when no default features.

My suggestion is to use io::read to read the stream data. If wasm is large.

@lum1n0us Could you review this PR?

[ivmarkov]

@lum1n0us We also need this support in the meantime. Do you think you can get some time to review, and eventually get this merged?

Using no_std is definitely a challenge for library developers, since core is a subset of the std crate. Without access to alloc and advanced features (like Vec and String), developers face many limitations in programming. However, libraries also gain strong compatibility and cross-platform capabilities by using no_std.

Fortunately, alloc is perfectly usable on no_std. And cross-platform. Sorry for stating the obvious but so that everyone is aligned on that.

Whether using alloc is tolerable - especially on (baremetal) MCUs where heap in general is a bit frowned upon is another question. Specifically for us, no_std + alloc is fine for... reasons.

As for the Module::from_file and the other stuff that needs STD, hiding it behind a feature = "std" gate as this PR does is just fine I think, until / if ever we figure out we need support for embedded_io(_async)::Read/Write.