kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 9/19/2016 9:52 AM, Michael Steinberg wrote:
> Hello Wayne, Torsten & All,
> 
> 
> Am 19.09.2016 um 15:17 schrieb Wayne Stambaugh:
>> I'm going to make an executive decision here so this doesn't drag on.
>> In short, swig stays.  Any other python bindings would either be on top
>> of or along side current swig bindings.  Swig is a valid tool for
>> generating scripting language bindings.  Lots of other projects use it
>> with great success so it can't be all bad.  We already have a large
>> investment of time in the current swig bindings along with lots of
>> project and user scripts that use them.  I do not want to discard that
>> investment of time and effort.  If anyone feels so inclined to write
>> some other python interface, there cannot be namespace clashes with the
>> current python bindings.
>>
>> On 9/19/2016 5:49 AM, "Torsten Hüter" wrote:
>>> Hi Tom & Michael,
>>>   I'm using the scripting interface quite often and had never that much
>>> trouble with it.
>>> The currently missing std::unique_ptr is not an argument, it is still
>>> possible to use it, see
>>> http://stackoverflow.com/questions/27693812/how-to-handle-unique-ptrs-with-swig
>>>
>>>   I'm quite sure that in the future almost any C++ 11 features will be
>>> supported by swig.
>>> Pybind is - as you have written - generatorless, in my opinion this is
>>> exactly the downside.
>>> You have to write wrappers yourself, while with swig you're simply
>>> including headers in the *.i files.
>>>   
> 
> I'm fine with staying with SWIG (See I also added it in the points of
> possible options twice). But still I'm left with contradicting
> statements about the stability of the blobs the current SWIG headers
> spit out. While Wayne's main point is that we cannot break existing
> scripts, Thorsten says that is no problem at all. If refactoring and
> exporting it like usual is no problem, then I have nothing left to
> argument about, because the initial problem I was addressing was
> non-existant to begin with (I'd like that, because it means no work!).
> If that is not the case, just saying SWIG stays is fixing the
> technicality, but not the specified API concerns imho.
> 
> Michael
> 

I'm not suggesting that we will always have absolute api stability.  I'm
not sure that is even realistic.  I can't think of a project of any
significance that's been around for any length of time who's api didn't
break something at some point.  Yes, event the C language had it's
moments way back when.  There may be occasions when we have to break
existing behavior.  However, most of the low level objects in pcbnew
have not changed significantly over the last few years.  We've added new
functions to the api but we haven't made major changes to the existing
api.  I don't remember anyone ever complaining about this but I may have
missed it.