On 2012-10-22 19:27, timotheecour wrote:
SWIG requires some kind of interface files, which I assume one must
have to manually write. Then what's the difference?
These can be as small as:
sfml.i:
%{
#include <SFML/Audio.hpp>
%}
%include SFML/Config.hpp
%include SFML/Audio/Export.hpp
In practice, some additional tweaks may be needed to support certain
constructs like multiple inheritance, etc, but nothing daunting (~ 50
lines of code for my sfml interface file)
I don't think SWIG is the right approach because:
* You have to create these interface files
=>
see above. Interface files can be very small.
* It seem to not handle all code
I was still able to port large libraries like sfml and opencv, using
tweaks to the interface files and enhancing swig to support C++template
to D template conversion. There's a small number of cases where swig
currently chokes, some of which could be easily fixed if there's enough
demand.
* No support for Objective-C
=>
http://www.swig.org/Doc1.1/HTML/SWIG.html#n7
One of SWIG's most recent additions is support for Objective-C parsing.
This is currently an experimental feature that may be improved in future
releases.
BTW, how does SWIG handle macros and documentation?
You'd have to write a C/C++ function that does what the macro does in
the interface file, which would in turn be converted to a D function.
For exporting C documentation to D, I've asked on stackoverflow:
http://stackoverflow.com/questions/12413957/export-comments-in-swig-wrapper
I'm not sure it's supported ATM, but that's definitely something
possible since swig has a full blown C++ parser.
Ok, I see.
If SWIG has a full blown C++ parser, then why is it choking on some
code? Or does it need a semantic analyzer as well.
--
/Jacob Carlborg
