Deimos (How to port a header)

[Johannes Pfau]

On Thursday, 31 January 2013 at 20:42:47 UTC, Marco Leise wrote:
> Maybe Deimos (the GitHub presence) could use a dry piece of
> text that explains how to convert a header. I have just had
> the need for xcb for example, but no idea how a good header
> translation is supposed to look like, if all files need to be
> converted already on the first go and other questions, like if
> all functions should be marked nothrow for example.

We should probably start a wiki page.

Regarding nothrow: I'm not really sure if this is officially 
supported, but at least on linux with dwarf exceptions you can 
throw exceptions between language boundaries. So a C function 
might call a extern(C) callback function implemented in D which 
might throw. In those cases C functions shouldn't be nothrow. In 
99% of all cases C functions don't call callbacks and therefore 
can be nothrow. Deimos does not enforce any rules though. (I 
think there was a discussion that D doesn't officially support 
throwing exceptions across language boundaries. In that case you 
could mark all C fuctions as nothrow, but you'd have to make sure 
that all callback functions passed to C are nothrow as well.)

>
> Also it looks like a long on Windows is 32-bit while on Linux
> it depends on the machine word size and libraries like xcb use
> "architecture dependent includes" for whatever that means in
> praxis.

You can use core.stdc.config's c_long and c_ulong. What's more 
problematic is that we'd also need a c_int and c_short. But for 
the currently supported architectures it's not necessary.

If you need types like int8_t we have core.stdc.stdint. In 
general if a c binding for your type declarations exists, just 
use that. If your c types are defined with some weird 
proprocessor stuff, but the intention is that they always have a 
fixed size there's a simple solution: you can just implement them 
as aliases to the D type with the same type and forget about the 
C preprocessor crap.

>
> There was even a "Variant" struct that gets additional fields,
> if the system compiler supports 64-bit ints. This can get ugly
> really fast and I just went with the comment that said that
> all interesting compilers support some kind of 64-bit int.

You can't know from D if the C comiler supports 64bit integers, 
so there's nothing you can do. A nice solution would be to use 
something like version(cHasNo64Int) so users of the binding can 
still manually force that mode by setting the version.

>
> So my impression is that currently only people with a
> good background of C on multiple platforms can reliably create
> Deimos bindings, unless they share their insights, possibly as
> a link from GitHub/Deimos to the Wiki on dlang.org.
> ("Aldacron"'s blog post is a great start, but I'm looking for
> something extendable and collaborative.)

Yep, that should really be done. Writing bindings for complex C 
libraries can require some C knowlege though (e.g. when you have 
to convert weird macros or strange C array syntax or function 
pointer syntax).

>
> I just imagined if I wrote DBus bindings and someone else
> wrote XCB bindings, we can share and benefit both. Also Deimos
> is ideal to be imported as Git sub-modules in other projects.
> A native D GUI library needs that stuff as well in the long
> term.