kicad-developers team mailing list archive
Mailing list archive
Re: DRC marker persistence
> On 3 Mar 2020, at 13:33, Henrik Hansen <Henrik.Enggaard@xxxxxxxxx> wrote:
> 1) As long as files with markers can be easily shared between people it is good.
> Why isn't "bloated diff" a problem for storing the markers in the project files?
I don’t think people diff their project files, but I know some of them diff their board files.
> Would it make sense to have an option to not store the markers?
That’s another option.
> 2) The second scenario of marking a specific error is the least surprising. How frequently will there be multiple errors of a certain type between the two same objects? That is a risky scenario, but it is hard to asses without knowing the chance.
It’s not for multiple errors, but for running DRC again. So if I mark “ignore pad to pad clearance between pads 1 and 7 of U22”, when I run DRC again it will still ignore it. (The risk is that I might have moved them even closer together, and that while the first clearance violation was deemed acceptable, the second wouldn’t be. Then again, if you want to check again you can delete your ignore list.)
> Best regards,
> On Tue, Mar 3, 2020 at 11:04 AM Jeff Young <jeff@xxxxxxxxx <mailto:jeff@xxxxxxxxx>> wrote:
> Part of the 6.0 DRC architecture is marker persistence. This will allow you to work your way through a large set of DRC violations, flagging those that have already been checked as exceptions or some-such.
> Two questions:
> 1) Store markers in board file or project file?
> Board file is much easier (in fact currently zero-cost as it’s implemented in my tree), but it may cause heartache in “bloated diff” camp? (Note that you can always press Delete All Markers when you’re done with DRC, so you can choose to not have them in the board file.)
> 2) Should exceptions be of the form “ignore error type X between object Y and object Z”, or “this specific error condition is a false-positive”?
> The first is more like a C++ #pragma. The second is arguably “safer”, but requires storing hashes of the entire data-state of objects Y and Z. Likely expensive to calculate on large boards (and somewhat expensive to implement).
> Mailing list: https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~kicad-developers <https://launchpad.net/~kicad-developers>
> More help : https://help.launchpad.net/ListHelp <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