search

mlua-rs / mlua

High level Lua 5.4/5.3/5.2/5.1 (including LuaJIT) and Roblox Luau bindings to Rust with async/await support
Other
1.67k stars 135 forks source link

no_std support? #90

Open paulrouget opened 3 years ago

paulrouget commented 3 years ago

Is it planned/possible?

khvzak commented 3 years ago

It definitely should be possible, but not yet in plans for the 1.0 release.

Personaly I don't use Rust nostd support.

ildar commented 2 years ago

Anyone's working on no_std support?

olback commented 2 years ago

Anyone's working on no_std support?

I'm considering it... I just don't have the time at the moment.

j-hui commented 1 year ago

I'm quite interested in this. I've gotten the Lua VM just barely working on microcontrollers before, but I gave up because interfacing with it via C is quite tedious. I would love to get Lua running on microcontrollers with some help from mlua + other embedded Rust crates.

I've given this some thought and started looking into what it would take. Vendored, Lua5.{1,2,3,4} all seem to work fine for thumbv{6,7,8} targets, as long as I comment out the panic!() in the build script when it encounters an unknown target. I extended the CI to test these builds: https://github.com/j-hui/lua-src-rs/pull/1 Other embedded targets like riscv and xtensa should also work in theory, but I'm less familiar with their cross-compilation toolchain so I've not bothered setting that up in CI. Luau is probably also possible in theory, but the source code doesn't "just compile" like Lua's.

I also gotten mlua to the point where it's not complaining about its dependencies not compiling, though mlua itself isn't compiling yet: https://github.com/j-hui/mlua/pull/1

At some point, I plan on going through and assessing what parts of mlua simply need to be refactored to be no_std-compatible, and what parts need to be rewritten/simply aren't possible for no_std. Of course, Lua features like dynamic linking and file system access will not work, so mlua features that expose/depend on those capabilities will probably not make sense either for a no_std target. But features like serde and async should work, in theory.

I hope to eventually produce a PR that at least illustrates what it would take for a no_std-compatible mlua. I'm primarily interested in getting things working on an rp2040, but plan to test this on at least one STM and NRF board as well.