kicad-developers team mailing list archive

[Michael Steinberg <michsteinb@xxxxxxxxx>]

Hello all!

Am 17.09.2016 um 23:39 schrieb Cirilo Bernardo:
> On Sat, Sep 17, 2016 at 2:08 AM, Tomasz Wlostowski 
> <tomasz.wlostowski@xxxxxxx <mailto:tomasz.wlostowski@xxxxxxx>> wrote:
>
>     [...]
>
>
> I agree with all that as well. I think the best thing to do is create 
> a PCB API
> which provides C bindings and people can make whatever scripting
> language API on top of that; this way there will be a much more uniform
> scheme for everyone. I was thinking about this while working on the STEP
> exporter but the more I looked at things, the bigger the job became.
> Eventually I thought it would take me a year or even more hacking at it
> part-time so I put it on the deferred list of things to do. Until we 
> have such
> an API, I think things will be a bit of a mess. On the other hand some
> people want a scripting API now and can't wait for some part-time coder
> to come up with something in a year or two.

So I conclude that we pretty much all agree it's a bad idea to export a 
rather unconstrained set of internals to python or any scripting. I 
think we also agree that we can't just drop the current state 
immediately. Beside these points I see a set of diverging technical 
strategies to implement it the right way (tm):

1.) Keep SWIG, wrap the output on the python side to a specified API
2.) Drop SWIG and interface with python.h ourselves without convenience 
libraries
3.) Drop SWIG, implement a C-API, write bindings in any language vs. C-API
4.) Drop SWIG, use compiler-based c++ bindings adhering the specified 
API (pybind11-like), using wrappers where necessary

What has not been mentioned for completeness:
5.) Keep SWIG, use a constrained export set possibly using wrappers to 
adhere the specified API

Anything missing from the list?

Of course every alternative takes a specified API for granted, where we 
haven none, yet. I cannot compare the techniques at the current point of 
time, since I simply have no experience creating a C-API for C++ code. 
Where some stuff seems obvious as how to get right, I need to think 
about technicalities of how to implement move-semantics, smart-pointers, 
etc.. I have some experience using techniques like pybind11 or luabind, 
where one doesn't have these problems, because C++ is not stripped away 
at the binding level. So I'll have to delve into it and play around 
creating a super-limited sample binding in every alternative just to 
come to a personal conclusion.
While the C-API seems like being the best solution technically, we'd 
need to develop the C-part and also convenience wrappers on the Python 
side just to be on par with the current state, right? Will there be 
enough developers with enough time to pull that off, I fear I doubt 
that, but as I said, I'll need to play around with this. It is however 
possible to create a binding vs. "the specified API" without taking this 
route, and it is also possible to switch the implementation technique 
later without changing the experienced binding semantics.
Just how large of a deprecation-timespan would you think is necessary to 
make such changes? I think there are "some" devs who are eager to go in 
and refactor quite some parts, but we simply cannot do this right now 
due to this problem. So we're pretty much in a state where we can only 
add stuff on top, right, where adding already means fixing it for the 
future, too?

Cheers!
Michael