kicad-developers team mailing list archive

[Florian Delizy <fdy@...>]

laurent.dufrechou@... wrote:
> Hi Florian,Dick,
>
> Here is an interesting thread :
> http://www.ogre3d.org/phpBB2/viewtopic.php?t=9375&highlight=&sid=ce193664e1d3d7c4af509e6f4e2718c6
>
> Well, like you will find on internet, you can sure find the opposite idea
> 
Yeah, that was one, thanks

> Florian, when you do the binding with pyste you need to modify the C++ code of
> kicad??
Actually, I did it in pure C++ code, I am not using pyste, mainly
because of the reason they mentionned on that thread.
> If yes, perhaps it could be interesting to take a look how evolved SWIG because,
> from what I remembered, doing the SWIG wrapper didn’t required from me to modify
> the C++ code.
Well, that's true on the Python calling C++ thing, but that will require
me a lot of work for the C++ calling python thing ... (yes that is a two
way binding ...)

> On this big project , I had the C++ code and I couldn’t modify, just adapt my
> SWIG .i code to make the binding.
> So I created a directory with my .i file and added a “make wrapper” to the
> makefile.
> Good point also with swig is the ability to map a C++ object to python one like
> C++ vector to python list etc…(with some work  )
> On my project, I had all C++ things, template metaprogramming etc… and I was
> able to support all C++ functions.
That's what SWIG is made for ;)
> I’m not telling you to change,
Well, I am maybe saying it ...
> I just give you the information from what was my
> experience with SWIG.
> Bad points where:
> -	Hard to learn at the beginning (but when you know how to do a thing it becomes
> quite easy)
I can handle that
> -	Hard to find info in the docs.
I can handle that too (code is the best doc :) )
> -	.i files are nearly a copy of .h files (but who cares, .h files evolves? Just
> copy the added methods in .i files)
well, I was thinking of writing a parser for that reason ... with
special macros such as __SWIG_EXPORT ...
> -	A new dependency for the project…
Boost is a dependency already, and that's quite hard to build on windows
(as JP. Charras told me).

other bad points includes :

- Drastically increase the compile time (something like x2 or x3 ... man
SWIG is slow !)
- May proove really painfull to use on the C++ calling other language
thing (although I read a thread explaining bits of it ...)
- Increase complexity of the code (you got to know what you are doing
... and few devs know SWIG), that point can be solved with some macro magic

but still, good points are:

- Handle multiple languages (maybe for future ?)
- Wx is using SWIG, inheritance will probably be easier that way
- SWIG allows to get a cleaner interface, and I think that's the killing
point for a project like that

Right now, I am playing a bit with SWIG, see if I can do what I need,
and if so, I'll hack away the boost.Python code, and work on SWIG. Maybe
writing a parser first. The real problem I had when I first tried was
the C++ calling Python thing ... couldn't make it work, but SWIG evolved
since then.

--

Florian