On Monday, 22 October 2012 at 06:28:12 UTC, Jacob Carlborg wrote:
On 2012-10-21 21:45, timotheecour wrote:
Manually porting of C/C++ libraries shouldn't be the way to go
(a
major problem being when said library gets updated, human
errors,
porting to different architectures etc).
SWIG requires some kind of interface files, which I assume one
must have to manually write. Then what's the difference?
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.
-- Brad
