Seeking Advice on D Bindings for Large C Library Collection

Rikki Cattermole via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Tue May 20 04:10:50 PDT 2014


On 20/05/2014 10:36 p.m., Tom Browder via Digitalmars-d-learn wrote:
> I am working on a project  to provide D binding files for the C/C++
> FOSS BRL-CAD project:
>
>    http://brlcad.org
>
> My work is on the "d-binding" branch and specifically here:
>
>    http://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/branches/d-binding/misc/d-bindings/
>
> My plan is to automatically generate the D binding files using Perl
> code that I'm writing.  (I have tried dstep but it's not working for
> me and I don't have time nor the D knowledge to go down that path at
> the moment.)
 >
> === Directory, File, and Module Organization
>
> One concern is the organization of the D files.  Letting $BRL be the
> root directory of the installed BRL-CAD package, its public headers
> are in
>
>    $BRL/include/brlcad/
>
> (with several sub-dirs not directly called by users).  Those headers
> privately access some other headers in
>
>    $BRL/include/
>
> (also with sub-dirs).  I plan to install the generated D interface
> files (initially as source) in
>
>    $BRL/d/


I assume that'll just be the working directory? Since it would be more 
useful as a dub repository.

> I plan to map the C header files this way:
>
>    # all public api (for headers found in installed dir
>    # "$BRL/include/brlcad" and its sub-dirs)
>    $BRL/d/X.d       # module name: brlcad.X (includes all X/* headers)
>    ...
>
>    # other brlcad-specific, private installed headers
>
>    # "$BRLCAD_ROOT/include"
>    $BRL/d/other/X.d  # module name: brlcad.other.X
>    ...
>
>    # for subdirs X
>    # "$BRLCAD_ROOT/include/X"
>    ./di/X/Y.d      # module name: brlcad.X.Y
>    ...

Just a suggestion if you were not aware, but gcc is able to output the 
entire headers as a single file that it is using, given a file.
Might be helpful if you want to say choose x headers (using #define) per 
D module.

> === System Headers and Other, Dependent Library Headers
>
> Another major concern is what to do about other, non-BRL-CAD headers:
> I see many system headers that don't seem to be covered by  Phobos.
> In addition, BRL-CAD has several other library dependencies that have
> no published D bindings that I have found yet (although two large
> ones, OpenGL and Tcl/Tk, seem to have such).
>
> I am gaining confidence that I can automatically generate D interface
> files with little to no manual intervention (given the guidance on the
> D Wiki), so my first inclination is to generate D files for all
> headers I find.
>
> I know I'm probably whistling through the dependency-graveyard here,
> but it's been an interesting walk so far.  However, I will appreciate
> any thoughts on the directory layout and file and module naming
> conventions.

Don't worry about it. If its really that big of a deal, separate project :)

Although personally I'm more concerned with the usage of templates at 
least from what I saw. That may be a little harder and may require a c 
lib as well to bind it together.

Will definitely be interested in your work if we can generate models in 
D and output them including textures! (I killed off blender numerous 
times via Python doing this)


More information about the Digitalmars-d-learn mailing list