lit make lit://luvit/luvit creates unusable binary after get-lit
squeek502 opened this issue · 4 comments
Luvit's package.lua specifies luvi 2.7.6 but get-lit downloads luvi 2.9.1 and compiles lit using that,
so then when you run lit make lit://luvit/luvit it downloads luvi 2.7.1 and makes luvit using that:
lit version: 3.7.0
luvi version: v2.9.1
command: make lit://luvit/luvit
load config: /home/ryan/.litconfig
connecting: wss://lit.luvit.io/
using snapshot: 6e805fb6a48f25304cc6553f18a01ecc30f10e30
creating binary: luvit
downloading: https://github.com/luvit/luvi/releases/download/v2.7.6/luvi-regular-Linux_x86_64
inserting luvi: /home/ryan/.litdb.git/cache/b46077e494b4a2647185c01af2ac46a3afbc2cb6/luvi
...
Luvit then throws this error if you try to run it:
/home/tim/luvi/src/lua/luvibundle.lua:321: bundle:deps/require.lua: cannot load incompatible bytecode
So either we need to make those versions match (update luvit to use same luvi as get-lit), or fix the cause of the error (is it a false positive?).
Note that get-lit itself builds a working version of luvit, it's only if you run lit make lit://luvit/luvit without specifying the input luvi (or if the input luvi doesn't match the luvi that your version of lit was built with) that it produces a broken luvit.
Me:
any reason why lit's luvi needs to match the luvi it uses when doing
lit make?
it compiles some of the lua files to bytecode
(it actually compiles all files, but only keeps the compiled version if it's smaller than the lua source)
we could just disable that part for now, it never was a big win
but also, we should update package.lua to depend on the latest luvi
instead we could have optional build flags to compile all or conditionally compile
but default should probably be source lua
Note: Updating Luvi in Luvit's package.lua is blocked by luvit/luvit#1058
I support the not compiling to bytecode by default option.