digitalmars.D - Automatic binding generation
- Piotr Szturmaj (22/22) Jan 06 2012 Is should be possible to use debug info of a library to generate D or
- Trass3r (4/4) Jan 06 2012 What you will get is completely platform-dependent.
- Jacob Carlborg (4/8) Jan 06 2012 I'm working on that, slowly.
- Trass3r (9/15) Jan 07 2012 btw, I wonder if it's all that good to do that as a clang fork.
- Jacob Carlborg (6/20) Jan 07 2012 I'm rewriting it using the Clang C bindings, using Clang as a library.
- MrOrdinaire (3/28) Jan 18 2013 May I ask what is the status of this project? Manually writing
- Jacob Carlborg (10/12) Jan 19 2013 It's working for all C constructs. I have mad one release. What it
- Jacob Carlborg (5/7) Jan 19 2013 I haven't been able to link it on Windows due to optlink not willing to
- bls (6/28) Jan 06 2012 Sure, not exactly what you have in mind, but at least an exotic thought
Is should be possible to use debug info of a library to generate D or other language bindings. Current approaches are SWIG, htod and/or manual coding. The first two do not always work as expected (try using them to make OpenCV bindings) as parser-based converters do not always support all build environment details. Often, you need a fully capable C/C++ compiler to correctly parse headers. Function information may be extracted from: * PDB files using DIA SDK on Windows * DWARF info using libdwarf or libdw on *nixes Debug files contain information about functions, their argument types and return types, about structs and classes/namespaces (C++). Recent version of DWARF may even contain information about macros. The usual binding creation would be simple: 1. build library using existing build environment with debug info bindings as well) Thanks to the 1st point we can avoid many incompatibilities with SWIG/htod parsers as we get all symbols in one file. The whole process may be automated in most circumstances. Eventually some fixup files may be used to assist with conversion (similar to SWIG files, but without enumerating everything). Thoughts?
Jan 06 2012
What you will get is completely platform-dependent. The only proper solution is using something like clang to write a C++->D converter. First only headers, later source code.
Jan 06 2012
On 2012-01-06 21:51, Trass3r wrote:What you will get is completely platform-dependent. The only proper solution is using something like clang to write a C++->D converter. First only headers, later source code.I'm working on that, slowly. -- /Jacob Carlborg
Jan 06 2012
On Friday, 6 January 2012 at 23:48:31 UTC, Jacob Carlborg wrote:On 2012-01-06 21:51, Trass3r wrote:btw, I wonder if it's all that good to do that as a clang fork. You will merge upstream from time to time and their countless commits will clutter the history, so it becomes hard to find out what really belongs to your tool. Also it shouldn't be a modified clang executable with a new -rewrite option anyway. One doesn't want nor need a full compiler. no codegen, no countless cmdline options (just some like -I etc.).The only proper solution is using something like clang to write a C++->D converter. First only headers, later source code.I'm working on that, slowly.
Jan 07 2012
On 2012-01-07 10:31, Trass3r wrote:On Friday, 6 January 2012 at 23:48:31 UTC, Jacob Carlborg wrote:I'm rewriting it using the Clang C bindings, using Clang as a library. I'm just hoping I will be able to do all the things I need to do with the C bindings. -- /Jacob CarlborgOn 2012-01-06 21:51, Trass3r wrote:btw, I wonder if it's all that good to do that as a clang fork. You will merge upstream from time to time and their countless commits will clutter the history, so it becomes hard to find out what really belongs to your tool. Also it shouldn't be a modified clang executable with a new -rewrite option anyway. One doesn't want nor need a full compiler. no codegen, no countless cmdline options (just some like -I etc.).The only proper solution is using something like clang to write a C++->D converter. First only headers, later source code.I'm working on that, slowly.
Jan 07 2012
On Saturday, 7 January 2012 at 14:05:57 UTC, Jacob Carlborg wrote:On 2012-01-07 10:31, Trass3r wrote:May I ask what is the status of this project? Manually writing bindings is error-prone and no fun at all.On Friday, 6 January 2012 at 23:48:31 UTC, Jacob Carlborg wrote:I'm rewriting it using the Clang C bindings, using Clang as a library. I'm just hoping I will be able to do all the things I need to do with the C bindings.On 2012-01-06 21:51, Trass3r wrote:btw, I wonder if it's all that good to do that as a clang fork. You will merge upstream from time to time and their countless commits will clutter the history, so it becomes hard to find out what really belongs to your tool. Also it shouldn't be a modified clang executable with a new -rewrite option anyway. One doesn't want nor need a full compiler. no codegen, no countless cmdline options (just some like -I etc.).The only proper solution is using something like clang to write a C++->D converter. First only headers, later source code.I'm working on that, slowly.
Jan 18 2013
On 2013-01-19 03:03, MrOrdinaire wrote:May I ask what is the status of this project? Manually writing bindings is error-prone and no fun at all.It's working for all C constructs. I have mad one release. What it cannot handle is the preprocessor. And it doesn't handle includes very well. It can only handle one file at the time. Except from that it's working pretty good. https://github.com/jacob-carlborg/dstep There's binaries for Mac OS X and Linux: https://github.com/jacob-carlborg/dstep/downloads -- /Jacob Carlborg
Jan 19 2013
Jacob Carlborg <doob me.com> On 2013-01-19 15:48, Jacob Carlborg wrote:There's binaries for Mac OS X and Linux: https://github.com/jacob-carlborg/dstep/downloadsI haven't been able to link it on Windows due to optlink not willing to cooperate. -- /Jacob Carlborg
Jan 19 2013
On 01/06/2012 12:34 PM, Piotr Szturmaj wrote:Is should be possible to use debug info of a library to generate D or other language bindings. Current approaches are SWIG, htod and/or manual coding. The first two do not always work as expected (try using them to make OpenCV bindings) as parser-based converters do not always support all build environment details. Often, you need a fully capable C/C++ compiler to correctly parse headers. Function information may be extracted from: * PDB files using DIA SDK on Windows * DWARF info using libdwarf or libdw on *nixes Debug files contain information about functions, their argument types and return types, about structs and classes/namespaces (C++). Recent version of DWARF may even contain information about macros. The usual binding creation would be simple: 1. build library using existing build environment with debug info bindings as well) Thanks to the 1st point we can avoid many incompatibilities with SWIG/htod parsers as we get all symbols in one file. The whole process may be automated in most circumstances. Eventually some fixup files may be used to assist with conversion (similar to SWIG files, but without enumerating everything). Thoughts?Sure, not exactly what you have in mind, but at least an exotic thought Source commenting -> Doxygen XML output -> XML to D. This is not as obscure as one might think, F.I. - GCCXML based bindings. - Ages ago I've talked with Frank (keinfarbton) about using Java2XML to automate SWT porting...
Jan 06 2012