[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Mike Pall's standalone FFI: a dream?
- From: "Dimiter \"malkia\" Stanev" <malkia@...>
- Date: Thu, 02 Jun 2011 11:39:33 -0700
On 5/12/2011 2:09 AM, steve donovan wrote:
On Thu, May 12, 2011 at 11:01 AM, KHMan<email@example.com> wrote:
Eh, my memory cells is a failure, a C preprocessor in Lua is probably more
like a 40KB stripped binary chunk. But it's under 20KB without the #if*
conditional syntax and expression parsing. There is quite a lot to
Oh yes, that's the complicated bit!
Although does it make sense to expect a Lua FFI package to read
implementation C header files? They are clunky and often depend on
lots of little bits. Much better to have a tool to massage them and
extract exactly what one wants, and include that. Such a tool could
start out by using the standalone C preprocessor as a first step.
Then (for instance) the target system only needs foo, not foo-dev
Take for example the simplest "struct dirent" - I needed opendir,
closedir, readdir etc. for my linux/osx machines, and wanted to use
through FFI - but the structure is different for each os, then
architecture, and even compilation mode (_POSIX_SOURCE or whatever there
Now for GCC there was a way to tell the preprocessor to spit all of it's
predefined macros, but for MSVC there is no way, unless you know what
macros are there (for example _WIN32, _MSC_VER, etc.)
On top of that, system header files being totally compiler dependent
they can contain things that are not even C (for example MSVC's SAL
mechanisms, uuids, etc.).
For that reason I'm still sticking to FFI, but looking for libs, that
are sanely written with same structures everywhere for every
architecture, or even if they are different, at most I can just say if
ffi.os == "Windows" then ffi.cdef("one way") else ffi.cdef("another