← Back to team overview

kicad-developers team mailing list archive

Re: Footprints: *.cmp and *.net stored footprints are not symetric


On 14.07.2014 11:55, Lorenzo Marcantonio wrote:

- eeschema writes netlist and reads netlist (detecting and incorporating
- cvpcb read netlist and write netlist (simply changes attributes)
- pcbnew read netlist and write netlist (saves its current states with

^^ 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.

- new tool reads two netlists and writes ECO for documentation purposes
   only :D

I think this is the simplest one to implement given the current
codebase. pcbnew has already all the netlist read/processing done, since
it's its main current use; it needs to be extended to write it back
(keeping around in core some bit it currently doesn't use to reproduce
it correctly, like component definition).

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).

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.

 so if there is a domain model (do we have it?) for the
netlist should be easy to do.  eeschema would be the most 'complex'
since it currently has no idea of reading the netlist and has to do the
diff processing. Given a domain model changing attributes for
backannotation is easy; in future gateswap would be easy (just change
the subpart) but portswap will not, since eeschema parts are very
tied to the library (they are instanced not copied like in pcbnew).
So why not copy them, just like pcbnew does? IIRC the model code in eeschema is to be reworked anyway...


Follow ups