Include KLC checks in library editors

[Antonio Vázquez Blanco]

Currently librarians use python check scripts to allow Travis to perform a rough check of wether a symbol or a footprint conforms with basic KLC rules.

Kicad library editors include a "DRC" or similar button that would be awesome if could include KLC checking.

The task would basically be porting the existing python code to KiCad to be able to perform the checks directly in the tool.

That would make checking easier for library collaborators and would lead to less work for librarians that are currently overwhelmed by the amounts of contributions to review.

[Antonio Vázquez Blanco (antoniovazquezblanco)]

I don't know anything about KiCad source code structure so I am not brave enough to provide a fix for this issue. On the other hand if a basic class structure was done by someone I would be willing to contribute with further work to migrate the existing checks.

[Wayne Stambaugh (stambaughw)]

It should not be terribly difficult at all to call the KLC from the footprint editor since python support is already in place for board and footprint editor. The symbol editor is a different story. Python support has not been implemented yet. Hopefully it will be part of the v6 development but that may be a stretch as there are plenty of tasks planned for v6. Until this happens your KLC implementation would only support footprints. I don't know how useful this would be.

[Antonio Vázquez Blanco (antoniovazquezblanco)]

From the quality point of view I believe that would be more desirable to use existing in memory information through existing C++ interfaces. Current python scripts read the corresponding item file, load it into memory, perform parsing through a completely different engine than the one used by KiCad and then perform checks. That looks like very inefficient to me, both from th execution and maintenance point of views.

 I think time would better be invested in providing a framework for porting the code into C++.

[Thomas Pointhuber (pointhi)]

I assume this is linked to future DRC and ERC improvements, to have the ability to add custom rules and scripts, as well as to have the ability to run DRC/ERC from the python interface.

[Wayne Stambaugh (stambaughw)]

The problem I have with this solution aside from the amount of effort
involved in implementing is keeping the code in kicad up to date with
the klc python scripts. Reusing the scripts makes more sense to me even
if it means improving the python scripts so they can be called without
using files. Although it would be easy enough to create a memory file
and pass that to the script.

On 11/15/2018 12:53 PM, Antonio Vázquez Blanco wrote:
>>From the quality point of view I believe that would be more desirable to
> use existing in memory information through existing C++ interfaces.
> Current python scripts read the corresponding item file, load it into
> memory, perform parsing through a completely different engine than the
> one used by KiCad and then perform checks. That looks like very
> inefficient to me, both from th execution and maintenance point of
> views.
>
> I think time would better be invested in providing a framework for
> porting the code into C++.
>

[Antonio Vázquez Blanco (antoniovazquezblanco)]

I have been working for a while now in CI for KiCad. I think it would be easy to pack KiCad into a docker image and use KiCad to generate the corresponding reports. Just as an idea.

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/2285