digitalmars.D.learn - Seeking Advice on D Bindings for Large C Library Collection
- Tom Browder via Digitalmars-d-learn (49/49) May 20 2014 I am working on a project to provide D binding files for the C/C++
- Rikki Cattermole (14/61) May 20 2014 I assume that'll just be the working directory? Since it would be more
- Tom Browder via Digitalmars-d-learn (22/41) May 20 2014 ...
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: ... ... ... === 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
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: ... ... ...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
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