kicad-developers team mailing list archive

["Dick H." <dick@...>]

This decision is an important one. Given the fact that the only two
people that have looked into the matter are not in harmonious
agreement, I would advise J.P. Charras that we discuss it further. 
The problem is that once these Python bindings start coming into the
code, they will have a very significant impact on maintainability and
comprehensibility of the project.  

Note that my mind is not set, but I am just leary that this is a very
important decision and crossing a bridge this important needs more
discussion.

So my questions to Florian are:

1) How much time did you spend with SWIG?


2) Are you aware that Boost.Python seems to require a different syntax
for various C++ compilers? (Microsoft) And that since it uses C++
templates it will ask more of the C++ compiler, i.e. pushing it?


3) If we wanted a very clean binding, it might even make sense to
consider http://sourceforge.net/projects/cxx/


Note that I have _a lot_ of experience with interfacing Java to C++,
and that experience tells me that a bolt on approach might not be as
good, long term, as an approach that could make the KICAD classes in
C++ be _fundamentally_ compatible with python.  

Therefore PyCXX, or something like it, at least needs consideration as
well. Let's just consider it and discuss it. We might be able to
tuck a base class underneath the existing C++ classes since they are
all derived from the same base class already.


And if we have not played with SWIG, let's play with it. A couple of
days spent experimenting will help us find the optimal solution.


You wouldn't start framing a house until the floor plan is agreed to,
and in fact you wouldn't want the lumber laying around the jobsite,
getting in the way, until the concrete foundation is poured. That
lumber getting in the way is my big concern, long term.

And yes, I want the nicest house possible.