kicad-developers team mailing list archive

[Antonio Vázquez Blanco <antoniovazquezblanco@xxxxxxxxx>]

>From the feedback given I am thinking about changing the proposal.

Given that my ultimate goal was to integrate KLC check into KiCad to
improve the quality of contributions and reduce librarian work, and that
seems conflicting we may need to re-think my approach to the problem.

I don't want to enforce KLC on every user. Furthermore, from your comments
I thought that maybe I am interested in even writing some tests that would
conform with a set of rules that only my organization would care about.
That being said, I came to the conclusion that maybe we could define groups
of tests that could be enabled or disabled depending on user preferences.
For example, KLC could be one of those groups of rules.

John suggested the usage of external scripts. That could be the solution to
various problems. Scripts could be externally updated if needed and they
would also allow to users to write their own checks without having to
recompille the full source code. It would also allow the distribution of
those "groups" of rules suggested above.

Maybe we sould think of a interface that would allow KiCad to look for a
set of Python scripts inside a particular folder to allow us to perform a
certain set of checks that would return result objects that KiCad could
later show.

Is this approach better? If so, given my lack of knowledge about KiCad
codebase, I would need some help designing that interface.

Thank you for your feedback!






El jue., 25 abr. 2019 a las 13:46, Wayne Stambaugh (<stambaughw@xxxxxxxxx>)
escribió:

> Antonio,
>
> Exactly what checks are you planning on implementing?  As long as they
> are generic in nature like off grid pin checking, then I'm fine with
> that.  If they are specific KLC checks like spacing, line width, etc,
> that is a different issue.  We should not be forcing KLC rules on all
> users.  If you wanted to make KLC style checks that can be customized
> and disabled to meet each users specific needs, I would be open to that.
>
> This code is not in the ERC code.  Symbol library tests are separate
> from the ERC and live in the symbol editor code.  You can find the
> symbol library editor code in the ./eeschema/libedit folder in the
> source tree.
>
> Thank you in your interest in contributing to KiCad.
>
> Cheers,
>
> Wayne
>
> On 4/25/19 5:39 AM, Antonio Vázquez Blanco wrote:
> > I've been playing around a little bit with KiCad source code lately and
> > in the forums [1] I was encouraged to write to the dev mailing list in
> > order to get feedback on how to improve the current library error
> checking.
> >
> > Summarizing the thread, I made some changes [2] so that a couple of KLC
> > checks are performed on syms but now that I've done that I would like to
> > implement this properly. I am looking for pointers on how should I
> > implement this so that the chances of me getting the code upstream
> > maximize and so that I can reuse the ERC/DRC code as much as possible.
> >
> > Thank you!
> >
> > [1] https://forum.kicad.info/t/improving-library-editor-checks/16557/5
> > [2]
> >
> https://gitlab.com/kicad-mirror/kicad-source-mirror/compare/master...feature%2Fklc
> >
> > _______________________________________________
> > 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
> >
>
> _______________________________________________
> 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
>