luajit-ffi

[Alex Rønne Petersen]

On 01-05-2012 18:56, so wrote:
> On Tuesday, 1 May 2012 at 16:46:32 UTC, Alex Rønne Petersen wrote:
>> On 01-05-2012 18:15, so wrote:
>>> On Tuesday, 1 May 2012 at 15:56:32 UTC, Alex Rønne Petersen wrote:
>>>
>>>> What are you talking about? The link you posted clearly shows that
>>>> LuaJIT has a C parser built in. It has everything to do with syntax
>>>> (note that FFI is not anything spectacular or innovative; see libffi,
>>>> Mono, Lisp, ...). And no, D does not "have all the structures". If it
>>>> did, we wouldn't be redefining them in D bindings.
>>>
>>> What am "i" talking about? How hard to understand these two things?
>>
>> Very hard! You're not making it clear what it is you want!
>>
>> Do you want something like LuaJIT's FFI so you can just drop a C
>> header in and get a binding or what? You really need to make this
>> clear. I'm not even sure what we're discussing at this point.
>
> Oh! Be prepared...
>
> import capi; // and you are done.

OK, I understand.

>
>> Yes... I wrote the libffi-d binding. You might want to have a look at
>> your local ffi.h and ffitarget.h to see why the preprocessor is a
>> serious problem in automated binding generation. As another example,
>> look at gc.h from libgc.
>>
>> No, not really. See above. It may be that simple for the OpenGL
>> headers, but frankly, OpenGL is an example of a reasonably designed
>> library, something that can't be said for 98% of all C libraries.
>
> As you said lets be realistic if we can support things like OpenGL/CL
> with tons of typedefs, enums, defines, function declerations (which you
> said seem to agree that easy). We could have 98% of mature C libraries.
> I don't agree with you on that 98% of mature libraries designed worse
> than those. Because since they target different languages they tend to
> have clean interfaces.

zlib.h, iconv.h, curses.h, arpa/inet.h, ev.h, expat.h, setjmp.h, 
ucontext.h, unwind.h ...

Just to name a few headers with subtle but problematic preprocessor usage.

How do you propose that we magically figure out what preprocessor 
definitions were given to the C compiler when the libraries were 
compiled? Not to mention what preprocessor definitions the compiler 
itself defines? And what about compiler extensions?

-- 
- Alex