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 beten, 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.
