Anyone with any ideas or commentary about how this task should be completed may add them here. Ideas about the details behind the implementation, too. Please refrain from deleting or significantly changing the meaning of someone else's entry.

This is what I'm thinking for the forward annotation (gsch2pcb) design:

The PCB has a list of schematics that it gets info from. Do we need path support, or is full-paths (or relative to the pcb) ok? Wildcards? Anyway, the list of schematics is stored in the .pcb file somehow. The GUI needs a way to manage these, too.

When the user asks, PCB uses the list of schematics to run a gnetlist command with my new backend, passing the list of schematics. The gnetlist spits out a list of actions, which pcb runs. These actions update the netlist, add any missing elements, and remove any appropriate elements. Elements which need new footprints are updated (magically! in place! we hope ;).

Also, some additional attributes will be propogated to elements, like vendor, vendor_part_number, etc.

If the import is part of a “new board” step, we place the parts and disperse them, optimize the rats nest, etc. No problem there.

What do we do with new elements if it's just an update? Eventually, I'd like to have some separate container for “unplaced elements” but I mean, what do we do for now? I'm wondering if disperse or autoplace is smart enough to do something useful if we place the parts and select them, on a partially laid out board.

I think this is enough information in the .pcb file that we can get rid of gsch2pcb and the “project” file it uses.

It does mean that the pcb cares which schematics go with it, but the schematics don't care which pcb they go with. Schematics can be reused/shared, boards generally can't.