Hello all!

Am 17.09.2016 um 23:39 schrieb Cirilo Bernardo:

On Sat, Sep 17, 2016 at 2:08 AM, Tomasz Wlostowski <tomasz.wlostow...@cern.ch <mailto:tomasz.wlostow...@cern.ch>> 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?

Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Reply via email to