Levente's Model? in -> process -> out
----------------------------------------------------------------- 1) sch, bom -> gschem (with db interface)-> sch, bom, ps 2) sch, bom -> gattrib (with db interface) -> sch, bom 3) sch, bom -> netlister -> netlist 4) netlist -> pcb -> gbr, cnc, ps, eco 5) sch, bom, eco -> netlister -> sch Steve Meier wrote: > in -> process -> out > > ----------------------------------------------------------------- > > 1) sch -> gschem -> sch, ps > > 2) sch, bom -> gattrib (with db interface) -> sch, bom > > 3) sch, bom -> netlister -> netlist > > 4) netlist -> pcb -> gbr, cnc, ps, eco > > 5) sch, bom, eco -> netlister -> sch > > I use netlister very liberally when I mean a libeda application that can > run scripts to manipulate the data structures and run scripts to output > in most any file format. > > eco is a file that has the difference between the input netlist and the > final netlist that represents the board > > Steve Meier > > > > > > DJ Delorie wrote: > >>> For the time being, however, I don't see any reason not to stick to >>> using some sort of external helper programs for actually accessing >>> the database, as long as we can get the UI and basic Scheme API >>> nailed down. >>> >>> >> I've argued in the past that gattrib should be responsible for >> attributes, not gschem. >> >> And, there's no reason why the attributes need to be in the schematic! >> We can store them in the BOM. There's a pleasing symmetry to it: >> >> gschem uses *.sym files to make *.sch >> gattrib uses db files to make *.bom >> pcb uses *.fp files to make *.pcb >> >> The only interesting change is to gsch2pcb, which needs to read a >> *.bom file in addition to the schematics. >> >> >> >>>> The symbol files should be as light as possible, and we should make them >>>> heavy by adding information coming from the database. >>>> >>>> >>> Totally agree. >>> >>> >> I agree symbols should be as light as possible, but "adding to them" >> isn't a requirement - we can store them in the BOM. If we store the >> attributes there then we also have a clue about which attributes came >> from which programs, and the bom can store more than just a name/value >> pair - it can store an "origin" value (how the value got chosen), for >> example. >> >> I think the only things that need to be added to the symbols >> themselves are things that need to appear in the schematics - like pin >> numbers. We need a way to assign pin numbers to labelled pins so that >> you can see in the schematic which pins are which. Especially if we >> get back annotation working. >> >> >> _______________________________________________ >> geda-user mailing list >> [email protected] >> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user >> >> >> > > > > _______________________________________________ > geda-user mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > > _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
