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)
