kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

If you are just doing the footprint checks then using the pcbnew python
support should be fine.  Whether or not it gets accepted into kicad
depends on you commitment to maintaining it but you can always load and
run it as a third party script.  You will have to live with some api
breakage from time to time until the stable python api wrapper is
complete.  Typically there isn't too much breakage with the swigged
python api.

Wayne

On 4/30/19 9:03 AM, Antonio Vázquez Blanco wrote:
> 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 <mailto: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>
>     <mailto: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>
>     >     <mailto: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>
>     >     <mailto: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
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     More help   : https://help.launchpad.net/ListHelp
>