On Jun 3, 2008, at 10:24 AM, Peter Clifton wrote: > On Tue, 2008-06-03 at 08:41 -0600, John Doty wrote: >> 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. > > Ok, then you'd either have it invoke the appropriate command to update > all elements from the command line (within the Makefile), or perhaps > some config would be set to make the tools always prefer the library
AAARGHH! NOT THE *LIBRARY*! THE *PROJECT* *SYMBOL* *REPOSITORY*. Of course, we don't currently make a clear distinction here, and that's the root cause of the problems that embedding and gattrib are inadequate at solving. > copy of a resource rather than the cached copy (just warn in the > GUI if > it detects a change). > > I thought you were arguing in favour of the previous behaviour, > where it > is pretty hard, if impossible to auto-update the footprints in a .pcb > file. That's because you don't use a project-specific copy of the symbol. If you do, it's just Hs, change the footprint, make. > >> Unacceptable. In a large project, such warnings are lost in the spew. > > You can't have it both ways.. a GUI dialog which warns you something > broke, or something which can work from the command-line. > > What we should do is reduce un-necessary stdout / stderr spew, so that > any output which is printed is important information for you to > review. A worthy goal. Never achieved in any large-scale use of make that I've ever seen, though. > >> 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. > > PCB's behaviour is the complete opposite of this, no automatic updates > are possible. I don't use PCB. My customers all have their own PCB flows. But here, the issue for me is schematic reuse: the layout generally has to be redone for any new project, even if most of the schematics are reused from previous ones. > > For either case, without caching some hash at least (if not a complete > copy, like PCB), there is no hope for ANY user to be notified about > library changes. If you don't want notifications / to use the cached > copy, there is no reason I can see why it couldn't be turned off. > >> 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. > > I was talking about caching of a copy, or a hash value, not full > embedding with no subsequent use of external files. > > (PS. My current project only has 40 non-library symbols, and > coincidentally, about 40 schematic pages after Makefile + sed based > auto-generation of a few multi-channel sections). > > -- > 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
