kicad-developers team mailing list archive

[John Beard <john.j.beard@xxxxxxxxx>]

On 19 January 2019 23:55:02 GMT, Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx> wrote:

>It's going to be a very useful tool. I wrote similar tests in the past
>for the P&S and connectivity (and GAL and some other things too), but
>they remain in my private branches because they're too low quality IMHO
>to be published, so I doubly appreciate your efforts to develop a
>proper
>testing tool.

Glad it sounds useful. I think getting DRC functions broken out is going to allow all sorts of nice things: unit testing, benchmark/profiling targets and even better on-line DRC.

The first victim will be courtyard DRC, but I'm trying to make it relatively easy to add new ones. 

>Also, I don't think the tests need to be 100% usable on
>all the platforms we support at all times,

Perhaps not, but keeping them compiling means there's always a self-documenting "how to" for the code (same for unit tests), so IMO it's good practice to at least have them compiling. 

> I found most of their value
>comes from much easier instrumentation/reproduction of difficult bugs
>or
>optimizing complex algorithms (i.e. DRC) without messing with the GUI.

This is what I expect the utilities to be mostly used for too. 

>Concerning the link time (I'm not sure I understood you correclty), I
>used to link my tests directly against _pcbnew.kiface (with a custom
>makefile and changed symbol visibility in the main makefile) and only
>rebuilt the ._kiface DLL when I changed something inside it. This is of
>course not very portable/error-proof, but reduces link times a lot. In
>the long term, we should split these huge .kiface beasts into a more
>manageable set of DLLs.

I mean the lengthy time it takes to run, say, "make qa_pcbnew" after changing a file in the qa/pcbnew subdirectory. The same goes for the pcbnew target. Libcommon-only targets are not so bad, but still not that fast. Especially the qa_pcbnew target needs to be "correct", as it is what will eventually be called as part of CI testing.

Breaking out DLLs is probably the way to go, also for binary size. Simon's units refactor is probably the best start anyone has on that. 

Cheers, 

John