www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Deimos (How to port a header)

reply Marco Leise <Marco.Leise gmx.de> writes:
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.

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.

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.

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.)

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.

-- 
Marco
Jan 31 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-31 21:42, 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.


There's a tool, DStep, that can automatically translate C headers to D 
modules. It will require some manual adjustments, like adding imports:

https://github.com/jacob-carlborg/dstep

These contain some info about porting a C header to a D module:

http://dlang.org/interfaceToC.html
http://dlang.org/htod.html

There's also a series of blog post about porting creating bindings to C 
libraries, which I cannot find right now.


 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.


The size of "long" depends on what data model is used. To simplify, on 
Windows, "long" is always 32bit. On the rest of the platforms "long" is 
32 bit when compiling for a 32bit platform and 64 bit when compiling for 
a 64bit platform.

To be more precise:



-- 
/Jacob Carlborg
Jan 31 2013
prev sibling parent "Johannes Pfau" <nospam example.com> writes:
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.
Feb 01 2013