On Sun, 2008-12-21 at 11:15 -0500, Stuart Brorson wrote: > Hi -- > > > I guess the question here is this: > > > > Is the input which PCB reads a netlist + parts list with enough info to > > update the board? > > No.
It should be possibly to describe the whole design enough to do that though. > > Or is it an action script which contains specific verbs, such as "place > > component X", "delete component Y"? > > Yes. Also, verbs like > > (set_trace_width <X>); > (route_trace <X1, Y1> <X2, Y2>); > > Just MHO. Fine, add to the description... but you'll need to think carefully what object / entity in the design those attributes apply to. > > This is more like the current gsch2pcb, which needs to grok what's > > already on the board, then issues instructions to make an update. > > My thought is that the forward annotation file would carry all info > necessary to take the current .pcb file to whatever the new schematics > call out. That is, the fwd anno file would represent a delta between > the existing .pcb file and what's changed in the .sch files. That > means: The I thought that part of the idea was that gsch2pcb shouldn't have to understand the PCB file-format. (As well as not having to re-implement code for looking up and placing footprints). > * With the very first invocation of gsch2pcb, the output .fwd file > (or whatever suffix is chosen) would emit all commands necessary to > place all footprints outside the drawing area, create the netlist > inside of PCB, and also emit any other necessary info. > > * Thereafter, gsch2pcb would read both the .pcb and the .sch files, > and figure out what commands are necessary to update the .pcb file. I got the impression that this wasn't what DJ was doing, rather exporting enough information to create the whole design inside PCB. Which is IMO quite sensible. The action syntax DJ is proposing does fit your incremental update suggestion better though, and would also form a good basis for live updates of connectivity between running programs (actions sent over DBus). You just have to be careful who is responsible for understanding the format at both ends and being able to create a list of actions to sync them. (You're proposing gsch2pcb, I think DJ and I are proposing PCB). > This implies that gsch2pcb must be able to read and parse a .pcb file, > as well as a .sch file. The .sch part is easy -- use gnetlist. To > read & understand the .pcb file, gsch2pcb would probably be best off > calling functions living an a libpcb, which would also be used by PCB > itself to do its thing. > > Or am I completely off base? PCB can't export any sensible information at the moment. Only its DBus interface would be easily extended to support returning data, but that would be a divorce from the one-way action syntax it already has internally. > [....] > > OR; we could teach PCB to spot changes in those files it cares about on > > disk, and will automatically update once I've pressed the button to > > update the files in the project manager. > > Right. Or at least that's what I was thinking. Another variant.. PCB could look for an action script on disk, although that is more dangerous... it would need to delete it after running if it contained any actions which were harmful to execute twice on the same board. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev