• Piotr Szturmaj <bncrbme jadamspam.pl> Jan 06 2012
• "Trass3r" <un known.com> Jan 06 2012
• Jacob Carlborg <doob me.com> Jan 06 2012
• Jacob Carlborg <doob me.com> Jan 07 2012
• Jacob Carlborg <doob me.com> Jan 19 2013
• Jacob Carlborg <doob me.com> Jan 19 2013
• bls <bizprac orange.fr> Jan 06 2012
• "Trass3r" <un known.com> Jan 07 2012
• "MrOrdinaire" <mrordinaire gmail.com> Jan 18 2013

Piotr Szturmaj <bncrbme jadamspam.pl> writes:

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
2. run converter to generate D bindings (this may be used to make C#'s 
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?

"Trass3r" <un known.com> writes:

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.

Jacob Carlborg <doob me.com> writes:

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

Jacob Carlborg <doob me.com> writes:

On 2012-01-07 10:31, Trass3r wrote:
 On Friday, 6 January 2012 at 23:48:31 UTC, Jacob Carlborg wrote:
 On 2012-01-06 21:51, Trass3r wrote:
 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.


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


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 Carlborg

Jacob Carlborg <doob me.com> writes:

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

Jacob Carlborg <doob me.com> writes:

On 2013-01-19 15:48, Jacob Carlborg wrote:

 There's binaries for Mac OS X and Linux:

 https://github.com/jacob-carlborg/dstep/downloads


I haven't been able to link it on Windows due to optlink not willing to 
cooperate.

-- 
/Jacob Carlborg

bls <bizprac orange.fr> writes:

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
 2. run converter to generate D bindings (this may be used to make C#'s
 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...

"Trass3r" <un known.com> writes:

On Friday, 6 January 2012 at 23:48:31 UTC, Jacob Carlborg wrote:
 On 2012-01-06 21:51, Trass3r wrote:
 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.


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

"MrOrdinaire" <mrordinaire gmail.com> writes:

On Saturday, 7 January 2012 at 14:05:57 UTC, Jacob Carlborg wrote:
 On 2012-01-07 10:31, Trass3r wrote:
 On Friday, 6 January 2012 at 23:48:31 UTC, Jacob Carlborg 
 wrote:
 On 2012-01-06 21:51, Trass3r wrote:
 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.


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


 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.


May I ask what is the status of this project? Manually writing
bindings is error-prone and no fun at all.