kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 9/16/2016 2:13 PM, 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.
> 
> Michael
> 

The only way I could get behind this if it's implemented separately from
and in addition to the current swig wrappers.  This would preserve the
investment folks have in their existing python scripts and they could
decide which bindings they prefer.  Forcing this kind of change on users
generally doesn't end well.