kicad-developers team mailing list archive

[Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>]

On 14.07.2014 11:55, Lorenzo Marcantonio wrote:

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

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

Cheers,
Tom