Upstream this?

[psi29a]

Why not? :)

[fedapo]

The idea is great, but there are a few problems with the implementation.

• All CMake variables that would be used on the client side (within the user's CMakeLists.txt) start with LUA_. There is already the original Lua (different from LuaJIT) library that is using this prefix in vcpkg's port. I suggest to change it to LUAJIT_.
• The file used by find_package is called FindLua.cmake, it should be LuaConfig.cmake (or, better, LuaJITConfig.cmake for the reason above), because in this case you want Config Mode search rather than Module Mode search. See https://cmake.org/cmake/help/latest/command/find_package.html. I agree with the comment above that the change should be moved upstream. Ideally all the way to the original library to have one standard approach to LuaJIT+CMake.

[9chu]

Thank you, guys.

The CMake file in this project is originally copied from the Luavit project. At that time they haven't upgraded to the latest Luajit version, so I did some tiny modifications for use in my own projects.

The Luajit is built under the Makefile build system, which is complicated and targets many architectures that I don't have, so the migration is not fully tested and I'm not planning to make any pull requests on it (and seems there is no official Luajit repo on Github).

When I wrote this down, the Luavit's CMakefile is already upgraded to support the latest Luajit, maybe it's a better choice for people who are looking for an usable CMake build file for the Luajit project.

:)