kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

On Fri, Sep 16, 2016 at 08:13:13PM +0200, Michael Steinberg wrote:
> Hello Wayne,
> 
> >Yet.  I'm sure they are going to have to implement it at some point.
> >You can always write your own swig wrapper something like this:
> >http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig
> They had 5+ years to add support, they didn't. So I wouldn't count on it.
> >As some of you may or may not know, the new wxpython project phoenix is
> >using sip instead of swig so that in and of itself may put us in a
> >position where we have to change to sip.  I would rather wait and see
> >what shakes out with the new wxpython implementation rather than head
> >down a path that only has to be changed yet again.
> And another break, will we support SWIG, SIP and an interop layer?
> >>With this message I want to ask what is the common view whether it is
> >>okay to have SWIG thumbscrew the project's source code, considering
> >>there are alternative generators, and generatorless libraries like
> >>pybind11. Of those alternatives I would *personally* prefer the latter,
> >>as it is no black box and the binding generation is part of the normal
> >>c++ source code.
> >Honestly, changing scripting language generators does not thrill me at
> >this point in the project.  It would most likely break all of the python
> >scripting work done thus far which would create a lot backlash.
> It will only get worse as time is passing by building upon the current
> state.
> 
> I think we need
> 1) a specified python API
> 2) adapters that match the specified API to the source code
> 3) Helpers to generate the necessary binding from the API adapters. This can
> be done with the aid of libraries or manually.
> 
> It seems none of that is currently available, the current unspecified API
> holds the source code tight, with a generator that hinders refactoring to
> modern c++ style. So we only lose on both sides.

Agreed. We _already_ risk breaking a lot of scripts and generating
backlash any time we change something, because our script "API" is just
bindings on the internals.

Bear in mind, if we replace it with something else, we can add the new
API without removing the old one immediately, and migrate gradually.

> 
> Michael
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp