I'm happy to see that the project is still active. LuaJIT is really something special. I'm also glad that they're using rolling releases, as I felt "bad" for using something named LuaJIT 2.1 beta3 in a project since the target was ARM64.
[flagged]
LuaJIT uses rolling releases
11–20 of 61 posts
Re: LuaJIT uses rolling releases
#12> DO NOT use pseudo-releases or tarballs created by third parties. In particular, automatic tarballs made by GitHub and other mirrors are lacking the .git directory and will not properly build anymore. It's a little concerning that their build process relies on a .git directory being present. That's going to make it quite tough for packagers to actually package this.
I'm confused what you mean. What is a packager doing here? I always assumed that the intention of this library is that you, as a developer, compile and embed it in a product that needs a scripting engine. What use would a standalone LuaJIT package be?
It's available as a package, and a library, in most Linux distributions. It includes the library and the interpreter.
edit: I have a few scripts with #!/usr/bin/luajit as the shebang line.
Re: LuaJIT uses rolling releases
#13Would be nice to have support for S390 finished and merged. There are some PRs but they aren't ready yet.
Re: LuaJIT uses rolling releases
#14> DO NOT use pseudo-releases or tarballs created by third parties. In particular, automatic tarballs made by GitHub and other mirrors are lacking the .git directory and will not properly build anymore. It's a little concerning that their build process relies on a .git directory being present. That's going to make it quite tough for packagers to actually package this.
Surely a packager would be working off of the actual releases not a random git archive? And if they can’t wait for official releases, they’d be working off of the git repo?
> Surely a packager would be working off of the actual releases not a random git archive?
There are no official releases. To quote from the linked email:
> No release tarballs or binaries are made available. Please do not use obsolete versions from older tarballs or zip files. Please remove any outdated links to these downloads -- they will cease to work soon.
The only way to get a release version of LuaJIT is to compile it from the git repo.
Re: LuaJIT uses rolling releases
#15> DO NOT use pseudo-releases or tarballs created by third parties. In particular, automatic tarballs made by GitHub and other mirrors are lacking the .git directory and will not properly build anymore. It's a little concerning that their build process relies on a .git directory being present. That's going to make it quite tough for packagers to actually package this.
I'm confused what you mean. What is a packager doing here? I always assumed that the intention of this library is that you, as a developer, compile and embed it in a product that needs a scripting engine. What use would a standalone LuaJIT package be?
[deleted]
Re: LuaJIT uses rolling releases
#16Earlier quoted context omitted.
Surely a packager would be working off of the actual releases not a random git archive? And if they can’t wait for official releases, they’d be working off of the git repo?
> Surely a packager would be working off of the actual releases not a random git archive? There are no official releases. To quote from the linked email: > No release tarballs or binaries are made available. Please do not use obsolete versions from older tarballs or zip files. Please remove any outdated links to these downloads -- they will cease to work soon. The only way to get a release version of LuaJIT is to com…
> The only way to get a release version of LuaJIT is to compile it from the git repo.
It will be interesting to see how this is packaged in, say, Ubuntu. Will they assign their own version numbers? Dates?
Re: LuaJIT uses rolling releases
#17> DO NOT use pseudo-releases or tarballs created by third parties. In particular, automatic tarballs made by GitHub and other mirrors are lacking the .git directory and will not properly build anymore. It's a little concerning that their build process relies on a .git directory being present. That's going to make it quite tough for packagers to actually package this.
I've never needed to build LuaJIT as a git repo. Just download the tarball and did: make and make install; all I have is GNU make and GCC.
Am I missing something?
Re: LuaJIT uses rolling releases
#18Earlier quoted context omitted.
I'm confused what you mean. What is a packager doing here? I always assumed that the intention of this library is that you, as a developer, compile and embed it in a product that needs a scripting engine. What use would a standalone LuaJIT package be?
It's available as a package, and a library, in most Linux distributions. It includes the library and the interpreter. edit: I have a few scripts with #!/usr/bin/luajit as the shebang line.
Interesting, that's neat. Somehow didn't realize using it like this was an option, but now that you mention it...
Re: LuaJIT uses rolling releases
#19> DO NOT use pseudo-releases or tarballs created by third parties. In particular, automatic tarballs made by GitHub and other mirrors are lacking the .git directory and will not properly build anymore. It's a little concerning that their build process relies on a .git directory being present. That's going to make it quite tough for packagers to actually package this.
I've never needed to build LuaJIT as a git repo. Just download the tarball and did: make and make install; all I have is GNU make and GCC. Am I missing something?
The build script changed slightly four days ago, and you will need git in the future (and build from a checkout of the repo.)
Re: LuaJIT uses rolling releases
#20Earlier quoted context omitted.
It's available as a package, and a library, in most Linux distributions. It includes the library and the interpreter. edit: I have a few scripts with #!/usr/bin/luajit as the shebang line.
Interesting, that's neat. Somehow didn't realize using it like this was an option, but now that you mention it...
libluajit is a drop-in replacement for the regular liblua (v5.1)