kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

On Fri, Oct 30, 2015 at 7:34 AM, Mário Luzeiro <mrluzeiro@xxxxx> wrote:

> Hi Cirilo,
>
> > I have no plans for kicad and plugins to share code.
> > As I wrote, plugins do not need to link to kicad or know anything about
> its internal data structures.
>
> I understand that it don't need to be linked, but if you want to make a
> board exporter (eg: export a board to eagle) how does the plugin knows
> about the kicad structure of a board without knowing its internal
> structures?
> I expect that the plugin receives some input data structure to process?
>
>
It's very simple - as I wrote, the API provides function calls to create
and manipulate data.
The plugins really don't need to know anything about the internal data
structures. Since
the plugins do not need to link, they should use the API calls; each plugin
will receive the
pointers to the API functions which are essentially all callback functions.


>
> > For me that's ridiculous and would be a very bad thing for kicad. If
> people don't want
> > to pull in the source tree while working on plugins that's not my
> problem. If they don't
> > maintain their out of tree plugins if/when the API changes, that's not
> my problem. Why
> > would I waste time working on imaginary problems created by other people
> who aren't
> > contributing code to the official tree?
>
> I was just asking to understand what was the approach that you are
> thinking to follow as there are different possible ways of doing it and it
> was not clear (for me) before.
>
>
OK, I thought it was clear all the headers will be in kicad since we will
have some
in-tree plugins. I have no interest at all in out-of-tree plugins - it is
possible to create
them and I will not prevent people from making them, but it is other
people's
responsibility to maintain them and if there are problems they are the
problem of the
out-of-tree maintainers.

- Cirilo


> Thanks!
>
> Mario
>