Approaching using a header-only C library

[Trebgarta]

Just curious. My C is really, really rusty and my ffi knowledge is limited. To serve as an example, the lib I was interested in. AFAIK LuaJIT ffi ignores bodies.

Should I somehow compile the bodies into a .dll, and include that way?

[Inny]

That library in particular appears to be both C macro heavy, so I doubt ffi will work for it, plus it looks like it relies on blocking calls, which wouldn't work with the the stock love.run function (which creates an event loop, that you shouldn't block).

As for your original problem, the desire to use an immediate mode gui, you don't need an ffi library, have several preexisting options written in pure lua already, such as Suit: https://love2d.org/wiki/SUIT

[Trebgarta]

I already use SUIT. That wasnt very helpful- I am curious about how you would approach using any C-header only lib. Say GLM as another example?

I must say though, I am curious about what you mean by blocking calls. Can you give an example?

[pgimeno]

FFI lets you declare how to call the C functions. The functions themselves are in a separate binary file. For example, look at http://luajit.org/ext_ffi_tutorial.html - the example uses ZLib. You need the ZLib binary library (typically libz.so on Linux, not sure about other systems, from the example it may be zlib1.dll on Windows), then you use FFI to declare how the functions need to be called (parameters and so on) and call them.

[Trebgarta]

So there is no other way, I guess then I'll take the dust off of my C knowledge and try to compile it to a library dll then.

So what I should do is get the implementation of the header inside a C file and compile it to a dll, load that dll and copy paste function declarations to be able to use them.

Sounds like a lot of work but I'll give it a try sometime.

[pgimeno]

The idea is, you compile a library normally, using a C compiler. You then take the .h header files that define the API of the library and use them in FFI (possibly modifying them to do any preprocessing manually).

The library you mention is particularly difficult. The main library doesn't do any drawing; it needs a backend. It comes with several backend examples in https://github.com/vurtun/nuklear/tree/master/demo , but none of them is Löve. You'd have to figure out how to create a Löve backend. Not for the faint of heart, it seems.

[Inny]

I must say though, I am curious about what you mean by blocking calls. Can you give an example?

A blocking call is when you make a function call and your current code doesn't resume execution until the other function returns with the intended output you wanted. This is in contrast to an asynchronous call, which returns immediately and you must either poll for results later, wait for the event queue to report a result, or wait until a callback has been called.

All of the calls in love.filesystem are blocking, because blocking-calls are what we expect when dealing with filesystems, it's how we've all been taught. love.event.wait is also a blocking call, but it's rarely used because you're not supposed to block an event loop. Everyone uses love.event.poll (implicitly via the default love.run).

The reason I bring this up is because an immediate-mode GUI is something that looks blocking, however SUIT actually doesn't. But in something like a C library, it probably does block, which would be bad. It means your events don't get processed, so things like keyboard presses go ignored, window resizes aren't serviced, and so on and so forth.

[Tanner]

Looking briefly at the SDL/OpenGL example, I think the only thing you'd need to get access to from Love is the SDL_Window instance and, maybe the SDL_Events (but you might be able to work around that). Which mean's you're going to need access to Love's Window:getHandle which isn't exposed to Lua. This (someone correct me if I'm wrong) means that your best bet would be to compile your shared library against Love as well and get the SDL_Window instance there.

I wouldn't describe this as a good first foray into LuaJIT's FFI but it's also not impossible.

[Trebgarta]

I must say though, I am curious about what you mean by blocking calls. Can you give an example?

The reason I bring this up is because an immediate-mode GUI is something that looks blocking, however SUIT actually doesn't. But in something like a C library, it probably does block, which would be bad. It means your events don't get processed, so things like keyboard presses go ignored, window resizes aren't serviced, and so on and so forth.

I know what blocking is, though what might be blocking in this library? It doesnt listen to events on its own, it doesnt do I/O, it doesnt even draw until you give it a backend and make it draw.

The idea is, you compile a library normally, using a C compiler. You then take the .h header files that define the API of the library and use them in FFI (possibly modifying them to do any preprocessing manually).

The library you mention is particularly difficult. The main library doesn't do any drawing; it needs a backend. It comes with several backend examples in https://github.com/vurtun/nuklear/tree/master/demo , but none of them is Löve. You'd have to figure out how to create a Löve backend. Not for the faint of heart, it seems.

I never expected it to be easy

Though it does have SDL backend. Doesn't Löve use SDL too? I mean, löve3d depends on SDL to load gl functions.

[pgimeno]

I think Tanner explained better than I could, what you may need to do if you follow that route.