At one point I had suggested an intermediate database that mapped all the symbols, footprints, and other attributes together into instances of parts. So, you could pick "2-in NAND gate" in gschem, and later narrow it down to a specific NAND gate package, either by footprint or vendor part number, with gschem "knowing" what the range of options are based on its database. PCB would use the same database to further narrow it down, perhaps, resulting in (eventually) a BOM.
So this big database would have fields for vendor, part number, gschem symbol, "value", pcb footprint, and notes. Better would be one file/directory per vendor, to avoid duplicating that field all over the place. After you pick a symbol, gschem would know what the list of possible footprints are, and once you pick one, it would know the list of possible part numbers and/or vendors. Etc. The problem is that there's a lot of variation involved. We have a couple of resistor symbols, which do we put in the database? Eagle, IIRC, has symbol classes - and I've seen others do this too. You'd add a "resistor symbol" and one pops up. You can change this to some other type of resistor symbol, but it's still a resistor symbol. The database maps "resistor symbol" to a range of through and SMD footprints, like AX-300-25 or SMD-0603. You pick SMD-0603. Now it can give you a list of vendor part numbers, values, whatnot to choose from. You choose the "22.1k" value. Now there's a smaller list of vendor part numbers to choose from. You pick Digikey P22.1KHCT-ND. But my point is that it shouldn't be up to gschem or pcb individually to keep track of this information; it's something that needs to be shared by both and used by both equally, because the information is used to bridge the two. Anyway, just food for thought. DJ
