kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

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" <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> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>