Embedding moonglfw alongside static GLFW in a LuaJIT-based application (and related questions)

[rdw-software]

Hello! I've been looking into embedding GLFW into my Lua/C++ application and I was evaluating this project as a potential option.

While trying to integrate the library and build a quick prototype, I encountered the following problems:

1.1. The bindings seem to explicitly target Lua 5.3 (and higher). Any chance to also support LuaJIT (5.1)? 1.2. There's no way to specify the Lua(JIT) include directory to use directly in the Makefile 1.3. luaopen_moonglfw is defined in internal.h only, but not exposed via moonglfw.h (which I presume is the "public API"?)

Even if the above were resolved, there's still a few more questions:

2.1. Can the library be built without Vulkan support? I'm using WebGPU, which would target Metal on OSX and DX12 on Windows 2.2. It seems that the Init function attempts to load GLFW dynamically. If I'm embedding GLFW alongside moonglfw and linking statically to it, is there a way to use the functions it provides directly (no LoadLibrary etc.)?

Note: By "is there a way" I mean "could it feasibly be made to work this way and if yes, what is the best approach?".

I'm happy to pitch in, but I don't know if this is a supported use case and how difficult it would be to make the changes required.

Thank you for your time, and for making this project :)

[stetre]

Hi, I'll try to answer.

1.1 Yes, they target Lua 5.3 and higher. While I've included the lua-compat-5.3 module in the project, I don't plan to explictly support earlier versions, and especially not Lua-JIT which by now is an entire different language wrt the official (PUC) Lua.

1.2 The Makefile is kept as simple as possible so that one can modify it or replace it altogether to suit their needs (I follow the standard Lua approach here, where the makefiles are more an example of how to build, than an actual build system). The INCDIR variable controls the include path, by the way.

1.3 luaopen_moonglfw is the function that the Lua interpreter searches for to load the library when a script requires it (for more info, search for 'luaopen_a_b_c' in section 6.3 of the Lua manual ). The library doesn't actually have a public C API. moonglfw.h is just a placeholder for one if one will ever be needed (which I doubt, but it's a scheme I follow in all the libraries of the collection, for consistency).

2.1 It can (or at least, it should) be compiled and used on systems where Vulkan is not installed altogether.

2.2 I'm afraid that this would require quite a bit of work on the codebase. Besides, I do not see the point in doing it, since the end result must be a dynamic library anyway (a Lua C module, to be 'require'd by Lua scripts, and hence dynamically loadable). Or am I missing something?

I hope my answers are not too disappointing. By the way, if you just need a specific subset of GLFW in your application, you may consider writing ad hoc C bindings in it. It's not that hard, once you get the gist of it (in that case, feel free to 'steal' whatever you need from my codebase).

Stefano

[rdw-software]

Thanks for the swift response! It sounds like what I have in mind is straying a bit too far from the expected, no problem though.

My questions were posed from an embedder's point of view, where you'd use moonglfw in a Lua/C application and not consume it as a regular Lua module (DLL/SO). This part isn't really LuaJIT-specific, but it may be more advanced than is usual perhaps.

I figured it was a bit of a stretch. Still, it was worth confirming since it might've saved me some time. I'll create FFI bindings as usual.

[stetre]

Yeah, LuaJIT aside, it's exactly the subtle difference between 'embedding' and 'extending' that so often causes confusion.