www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Seeking Advice on D Bindings for Large C Library Collection

reply Tom Browder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
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 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
  ...

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

Best regards,

-Tom
May 20 2014
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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)
May 20 2014
parent Tom Browder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Tue, May 20, 2014 at 6:10 AM, Rikki Cattermole via
Digitalmars-d-learn <digitalmars-d-learn puremagic.com> wrote:
 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:
...
 (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.
No, as I have outlined it, it will be the dir for the public D interface files. For now I'm just trying to plan a working solution for the only user: me! One of the issues I will have to sort out for any public interface or repo is architecture, etc. But putting stuff in a dub repo (if all works) is definitely a next step.
 I plan to map the C header files this way:
...
 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.
Yes, I'm aware, but my thought is by going fine-grained, at least in the beginning, it will be easier to isolate conversion problems for manual intervention as necessary.
 === System Headers and Other, Dependent Library Headers

 Another major concern is what to do about other, non-BRL-CAD headers:
...
 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.
Well, so far I have not run into any C++ templates in the public API, but you may be looking at some specific C++ code. Most of the C++ code I'm familiar with has extern C interface headers. Sean Morrison, the BRL-CAD Daddy Rabbit, has intentionally kept the public API C-usable. Thanks for the input, Rikki, and your interest. Best regards, -Tom
May 20 2014