On Jun 3, 2008, at 4:22 AM, Peter Clifton wrote: > On Mon, 2008-06-02 at 19:14 -0600, John Doty wrote: >> On Jun 2, 2008, at 11:02 AM, Peter Clifton wrote: > >> What is "make" supposed to do with a dialog box? > > Nothing more than when it is expected to design your circuits for you.
I expect "make" to do what it does for software: propagate changes as needed. If I change the package of the default resistor in a project and type "make", I expect all data products for that project to reflect the change. > > > Console based processing would have to work as usual, perhaps > throwing a > stderr / stdout warning that there might be out-dated footprints for > certain files. Unacceptable. In a large project, such warnings are lost in the spew. > > There could also be a command line option / tool which specifically > checks these things and returns 0 / 1 / whatever, so you can make > further processing conditional on everything being "happy". When I change a symbol to fix a pin assignment, part number, footprint, underlying hierarchical schematic, etc., I expect that change to propagate. Among other things, it's part of design reuse: in prototype maybe the default resistor is 0603, but in production it's 0201. Some customers imagine hermetic packages improve reliability, others are more sensible. With symbol collections customized for the project, it's easy to move schematics from project to project (especially if you turn off automatic promotion of device and footprint attributes). So, low_noise_npn.sym represents BCX70K in an SOT23 in one project, 2N930JANTXV in a can in another. > > In the case of divergent footprints / symbols which the user _wants_, > I'd imagine the GUI action to express this would then take the desired > symbol and dissociate it from the library copy, either giving it a > different name, or just flagging so in the file. It seems to me that *all* project symbols should be disassociated from the library copy and placed in the project symbol repository (often under another name: low_noise_npn, small_resistor, etc.). But embedding them in a schematic is a severe barrier to schematic reuse in an different project. > There could be a > hash-code of the confirmed version stashed in the layout / schematic > which just ensures no further prompting unless the library version > changes again. The library is really only useful as a starting point, mostly for graphics. A project has its specific requirements that drive the device, footprint, and other part specifications. A schematic may be reused in several projects with different parts requirements. Keeping the part specs in project-specific symbols facilitates this. Gattrib is useful for the occasional exception (sometimes you can't shrink to an 0201), but is too time-consuming for managing common attributes in a big project. > > > -- > 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 > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [EMAIL PROTECTED] _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
