Re: LuaJIT FFI purely using .h files; and handling the multiple definition attempts

[Andrew Yourtchenko <ayourtch@...>]

On Sat, Feb 26, 2011 at 6:59 PM, Michal Kottman <k0mpjut0r@gmail.com> wrote:
> On Sat, 2011-02-26 at 18:26 +0100, Andrew Yourtchenko wrote:
>> The "include" part assumes the headers are in their places, and uses
>> the popen of "echo '#include <filename.h>' | gcc -E -" with some
>> filtering to get the data.
>>
>> This is all fine and dandy. The problem with this method is that it
>> produces duplicate definitions (since each include is treated
>> separately). This makes luajit unhappy.
>
> Well, exactly because of this problem, I preprocess all the include
> files at once - so that the preprocessor itself can remove all the
> duplicates. Maybe you could try something like this:
>
> ffi.include { "stdio.h", "time.h", "unistd.h", ... } -- you get the idea
>

yeah. That would make the work with FFI not very modular... I would
like to avoid that.

> Or, another way to do this is just to collect all the arguments into a
> table, and then use a function like processAllHeaders() that will do the
> same thing as I did manually.
>

This is a bit better, this might work.

> The last option (IMO not good) would be to patch LuaJIT to ignore
> redefinitions altogether...
>

That's what the patch I have does, but upon more thinking I think it
is a pretty bad idea.

And I think the best approach is actually to implement the
preprocessor itself. (whether as part of ffi - something like or as a
separate lua-only function)

http://mcpp.sourceforge.net/ seems to have a suitable license.

(Also for fun I've started to implement it as a Lua-only primitive -
https://github.com/ayourtch/luajit-fun/tree/master/cpp; but it is
pretty ugly code/dysfunctional at the moment, but can already do
simple substitutions).

Having a Lua-aware CPP would allow also to pull in the #define-d
primitives - which would be a plus.

cheers,
andrew