LuaJIT uses rolling releases
freelists.org
LuaJIT uses rolling releases
1–10 of 61 posts
Re: LuaJIT uses rolling releases
#2Also interesting is that https://luajit.org/status.html now states “LuaJIT is actively developed and maintained” (whereas for the last ~5 years, “actively” isn’t a word I’d have used), and makes reference to a TBA development branch.
Re: LuaJIT uses rolling releases
#3> 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.
Re: LuaJIT uses rolling releases
#4> 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 think https://github.com/LuaJIT/LuaJIT/commit/6a2163a6b45d6d251599... improved things a bit, notably making automatic tarballs work again.
Re: LuaJIT uses rolling releases
#5> 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?
Re: LuaJIT uses rolling releases
#6I'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.
Re: LuaJIT uses rolling releases
#7> 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.
Somewhat difficult to find on the linked list archive, but this exact issue was dicussed there. See the followup mails: https://www.freelists.org/archive/luajit/08-2023?threads=1
Re: LuaJIT uses rolling releases
#8Huh. I thought this project was abandoned, with the beta 2.1 being the latest version for many years now, and the new GC having never been implemented. But looking at the page now, all mention of this has been deleted. Has work on it resumed? Exciting!
Re: LuaJIT uses rolling releases
#9[flagged]
Re: LuaJIT uses rolling releases
#10> 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?