That sounds to me like it would make sense use kicad-python such that we can get yhe external API defined, and _ideally_ we could do whatever internally to kicad, let that be swig replacement or not.
I suspect that having the external API defined would make it easier to find a better implementation and tests. But I warn you, I am by no means an expert in this kind of work. Den 18/09/2016 16.15 skrev "Michael Steinberg" <michste...@gmail.com>: > 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> 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 > > _______________________________________________ > 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 > >
_______________________________________________ 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