On 2012-10-22 20:38, Brad Lanam wrote:
Huge difference. It's not necessary to figure out corresponding type
sizes on every system. I only need to figure out what needs to be in
there. And once all the work of creating the interface file is done,
the work of porting to another architecture or operating system or
compiler is much reduced.
It's not necessary to figure out which api calls are macros on arch XYZ
or are simply not there:
cdcl Tcl_IncrRefCount
clib Tcl_IncrRefCount
# if Tcl_IncrRefCount is not defined as a library call, search for the
macro.
if lib_Tcl_IncrRefCount ! _clib_Tcl_IncrRefCount
cmacro Tcl_IncrRefCount tcl.h void 'Tcl_Obj *'
endif
My example Tck/Tk conversion doesn't handle 8.6, but the effort to add
it will be very minimal. All of the hard work of discovering the needed
typedefs has been done.
[...]
I don't think SWIG is the right approach because:
* You have to create these interface files
* It seem to not handle all code
I don't know SWIG, but the idea is the same for my tool.
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. The included system definitions will conflict
with D definitions.
I'm not sure that handling *all* code is necessary. How often do you see
this sort of thing in C code?
_XPrivate .private9, .private10;
Rather than spend effort on handling *every* possible obscure C/C++/ObjC
construct, it's easier to simply handle those in the interface file.
Other constructs that are more common can be added to SWIG or to my tool.
They're both open source.
I prefer the approach I took when I created DStep, it uses libclang. The
tool can parse all C(++) and Objective-C(++) code that clang can.
Although it currently won't generate code for everything, at least it
doesn't choke any code.
I also get all bug fixes and new languages features for free when
they're added to clang.
No need to create interface files.
--
/Jacob Carlborg
