For some of these I use a $LUAJIT_LIBPATH
environment variable to specify the base of the directory structure where .so files are located.
From there sometimes I follow Malkia's structure of /$ffi.os/$ffi.arch/
to further distinguish .so files.
This is driven by my C preprocessor in Lua project, whose generate.lua
file will automatically generate the headers from the compiler's include files.
This is still a manually run and hand-tweaked process, but will hopefully eventually be automated into my #include-in-Lua project.
The original versions started from https://github.com/malkia/ufo .
The directory structure is a bit of a mess.
At first everything was just put in root.
Then I started porting C headers and putting them into the c
folder, so that luajit code require 'ffi.c.$header'
was equivalent to C code #include <$header.h>
.
(But, you ask, why only put the builtin C headers in the c
folder when the other libraries' headers go in the root folder? Good question.)
Then I started adding my own attempt at STL classes ported to LuaJIT classes in "lua-ffi-bindings/cpp",
so that luajit code require 'ffi.cpp.$header'
was equivalent to C++ code #include <$header>
.
... so far only "vector" exists but I might add more.
A few of my Lua class wrappers all started to exhibit the same pattern for refcounting (lua-opencl) or automatically deleting resources (lua-gl) ... so I decided to put that behavior in one place, here. Maybe I'll put that into its own unique repo soon.
- LuaJIT
- lua-ext
- template-lua
- preproc-lua optionally if you want to generate new headers. This requires C headers to be present, which is no problem on linux, but for Windows you'll have to have MSVC or MinGW or something installed.
In the future, I'm hoping to incorporate: