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 somecode? 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
