Re: LuaJIT Wiki?
- From: Adam Strzelecki <ono@xxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Tue, 8 May 2012 14:48:24 +0200
> I think one of the most pervasive problems with using FFI bindings is
> a lack of namespacing;
> whenever I use more than a single FFI based binding in a project I
> find that I get re-definition errors...
Same typdefs collisions would happen in C program as well anyway :)
But indeed it would be much better if cdef block, or even better .h file io
handle, could be passed to ffi.load to avoid namespace collisions.
> The other question I pose is:
> Should general FFI binding style be to store cleaned
> headers/declarations, or to rely for the headers to be present on the
> target system, and process them...
Relaying on OS headers won't work:
(1) you won't have headers unless you install some developertools, like MSVC,
MinGW on Windows or Xcode on Mac, but these are not needed if you run luajit
from binary distribution
(2) luajit has no complete C preprocessor yet AFAIR
But if it has C preprocessor, then we could embed .h files within module.
> Far too many libraries seem to have defines that change on a
> per-platform basis, and I don't like the idea of maintaining seperate
> cdefs for each target platform+version of the library.
Me neither. But again we would need to have complete C preprocessor, moreover
luajit would need to define all standard macros/values defined by the C
compiler on the target platform (mimic compiler).
Finally it would be awesome of luajit -b could compile .h files into bytecode
as it does with .lua files, so when deploying app we:
(1) won't waste time to parse .h headers
(2) reduce app package size
(3) don't expose headers
Cheers,
--
Adam Strzelecki
Other related posts:
