On Mon, Jul 14, 2014 at 01:12:48PM +0200, Tomasz Wlostowski wrote: > ^^ all of this could be likely done by the same piece of code, that simply > compares the two netlists and generates the differences. This part is > generic. The way the differences are resolved is specific to > pcbnew/eeschema/cvpcb. An ECO report/visual diff would be just a useful side > effect of this approach.
Correct. See my comment as 'could be a lib or a separate process'. The output format (in the sense of 'how this routine emits output' however *will* matter (can be put out on a file or drive the 'difference resolutor', more or less like an expat parser). > I don't think we need a separate tool. Our aim is to be able to see what > gets changed on the PCB/SCH and pick which changes to apply and reject. The > ECO you're talking about needs not be a physical file, it can be implicitly > generated whenever user requests updating the PCB/schematic. Most of the > code is probably already in place, what we want is to make it more > controllable (so that, for instance, you could undo a recent netlist update > in pcbnew). The 'separate tool' could be simply a wrapper for a lib call, as I said. Since you talked about documentation I tought it was needed some kind of output file. > >cvpcb only needs to touch the footprints > As agreed with Wayne, there's no place for cvpcb as a separate tool in the > future of Kicad. Footprint selection should be done on the schematic level. OK, that doesn't change very much the interaction model anyway (and cvpcb would be the easiest part). > So why not copy them, just like pcbnew does? IIRC the model code in eeschema > is to be reworked anyway... I think that would be for *another* proposal. The problem with the current model is that pin are fixed in position. So given the typical 7400: U1A --1--\ | O3-- --2--/ you can gateswap easily, the info *could* be already there: U1B --4--\ | O6-- --5--/ But how do you pinswap? U1A --2--\ | O3-- --1--/ ^ how? You could either a) duplicate and physically swap the pins on the part (more or less the way we do it on pcbnew) or b) use an indirection table to represent the mapping between, say 'logical pins' 1, 2 and physical pin 1 and 2. a) is IMHO more difficult to handle from a 'declarative' backannotation (how do you represent it?), b) is just another data structure to handle. -- Lorenzo Marcantonio Logos Srl _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
