Comment by VWWHFSfQ
1 year ago
This is just behind a feature flag like:
$ cargo add mlua --features lua54,vendored
Then mlua will statically build with the Lua sources it bundles itself and no need to link the system Lua or do anything other than "cargo build" like normal.
Still not as easy as pure Rust, e.g. for cross-compiling. It's similar to how pure Go projects are much easier to cross-compile than ones using cgo.
`cargo cross` exists, which can help but it's really a kludge.
This is a cargo deficiency then.
Zig has no problem using Lua (via the Ziglua wrapper) and cross-compilation is a single command away.
Rather than developing and increasingly insular (navel-gazing?) ecosystem, it might be better to work on the root problem.
Zig is first and foremost a C compiler with cross-compilation being first class citizen so you can't really compare the two.
> Rather than developing and increasingly insular (navel-gazing?) ecosystem, it might be better to work on the root problem.
Every language has its own development budget and must focus on what makes more sense. Zig has great cross-compiling story and C is first class, Rust has a stable language, a compiler that doesn't crash and emits readable error messages, one has to set its priorities.
The good thing with zig is that you can use the zig compiler within Rust project to cross-compile C code (cargo-zigbuild IIRC) so you can have a cake and eat it too.
This is a very uninformed take. It's not a Cargo or Go problem, it's a C problem. It only works well with Zig because Zig goes to insane lengths to hide the problem.
In fact it's so much of a C problem that lots of people even cross-compile their pure C code with Zig, because Zig handles all of the C mess!
You can educate yourself here: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
2 replies →