kicad-developers team mailing list archive

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

Maybe starting with footprint checking improvements is easier as python
scripting support seems more advanced and that would allow me to start
working on something. AFAIK there is SWIG for that part (I do not know how
stable it is but I am willing to cope with that). ¿What do you think about
that?

As pointed by users in the forum it would be interesting to be able to run
the check scripts from command line in order to integrate the checks into
Travis/Gitlab or whatever CI environment is going to be used. Also, current
check scripts implement their own parsing which I would like to avoid by
using KiCad implementation.

Thank you!

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

> Python scripting support is hopefully going to be implemented at some
> point during V6 development.  This should allow you to integrate the KLC
> scripts directly into the symbol library editor.  This will most likely
> happen late in V6 development because there are some major functional
> changes to the low level schematic and library objects.  It doesn't make
> sense to swig this until the low level object APIs stabilize.
>
> On 4/25/19 9:39 AM, Antonio Vázquez Blanco wrote:
> > 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 <mailto: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
> >     <mailto: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
> >     <mailto: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
> >
>
> _______________________________________________
> 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
>