More automated interfacing of D with C codebases

[Jacob Carlborg]

On 2012-10-23 07:09, timotheecour wrote:
>> If you try to automate processing of the pre-processed headers,
>> all of the included system headers will be processed and too much that
>> isn't needed will be output.
>
> Swig has lots of customization to control what gets translated. For
> example, we recursively translate the contents of header files or just
> the contents minus without looking into the include statements (the
> default):
>
> b.h:
> void funb();
> a.h:
> #include b.h
> void funa();
>
> %{
> %include "a.h"
> %}
> %include a.h
>
> => the default is NOT to inlude funb(), which is inside an include
> statement.

I'm only translating what's in the "main" header file, i.e. the one you 
gave on the command line. I have access to source information of where a 
given symbol is declared, if it doesn't match the main header file it's 
not translated.

>>> If SWIG has a full blown C++ parser, then why is it choking on some
> code?
> One example is when there's no D equivalent, eg multiple inheritance.
> But there are more:
> actually in the example above, if I understand correctly, the stuff
> inside the %{ %} uses the full blown C++ parser, whereas the stuff after
> has some swig specificities and sometimes can't handle certain rare
> constructs if one uses the lazy approach that I've taken of translating
> the whole header file (%include a.h):
>
> some stuff it choked on:
> A) typedef Matx<_Tp, MIN(m, n), 1> diag_type;
> B) void addParam(   int (Algorithm::*getter)()=0)

If there's something I can't translate to D I just skip it. I could 
output a warning, some kind of static assert in the code or whatever. 
The tool can still handle the file.

-- 
/Jacob Carlborg