Closed Duckwhale closed 5 months ago
Just a quick note for future me as to why embedding the cdefs turned out to be so overly complicated:
.incbin
didn't work)cdefs
at build time and embeds them just like all the other bytecode objectsxxd
to generate binary dump headers and include them in the codeIn short, all solutions are terrible and I'm not sure which one is the least of a headache. Give me std::embed
already, will you?
I really am not a fan of this given the increase in complexity. The drawbacks simply don't seem worth it (without std::embed
):
xxd
(and vim
as a package)cdef
string as wellSince one goal is to make sure the FFI and C++ definitions are always in sync, maybe there's a simpler way to get that benefit:
NULL
pointer values)This would still necessitate code duplication, but if the test suite catches any discrepancy then it might not be a huge problem.
Closing for now due to the above concerns. It's too large a PR to merge as-is anyway; will split off some parts when applicable.
Some of the definitions unfortunately can't be checked by the compiler. But overall, reduces the amount of boilerplate code:
bindings
module now contains both the exports and the cdefs for each embedded libraryThey're embedded as strings (via non-portable inline assembly) and so passed to LuaJIT, which is somewhat hackyMore cleanup will be needed to remove the
bindings
member of each library, but this is far too large already.