Open tomaka opened 7 years ago
Tests weren't passing because I used f32
instead of f64
for lua_Number
, which is something configurable with the build and that I have apparently misread.
I'm leaving this PR open for a little while in order to make sure that there is no opposition to it that I may not be aware of.
Would this impact any people using hlua with luajit?
@TyOverby The lua API is backward-compatible, so it shouldn't have any impact.
However lua 5.3 supports closures, which we may want to support in hlua eventually. If we do so then you'd get linking errors with luajit.
Could you use crate features for Lua versions? It would require more restructuring but it would make the crate more available in the future. You could also put the various Lua compilation options (i.e. number types, etc.) behind features but that might be too complicated.
@SnirkImmington I've looked into it, and I think it should be done directly in a lua-sys
crate.
If we release both a luajit-sys
and a lua53-sys
crate, then they will both contain a links
attribute to the lua library. This attribute is here in order to avoid symbol collision between libraries, and the consequence is that we wouldn't be able to depend on both libraries at the same time, even though we would only use one.
The lua API is backward-compatible
No, there are usually a few breaking changes and incompatibilities between each version. Each of 5.1, 5.2 and 5.3 should be thought of as separate, but related languages. Similar to Python 2 vs 3.
However since Lua is such a small language, it is usually not too much work to be compatible with a few versions.
lua 5.3 supports closures
Lua has supported closures for a long time, since 3.1 according to the version history page.
Tests aren't passing for an unknown reason.