On Jul 11, 2007, at 11:47 AM, Peter TB Brett wrote: > On Wednesday 11 July 2007 18:10:22 John Doty wrote: >> On Jul 11, 2007, at 5:38 AM, Ales Hvezda wrote: >>> Hi All, >>> >>> Question for the list, how would you feel if gschem's default >>> storage >>> mechanism changed from referencing to embedding placed symbols? >>> Instead of >>> just referencing the symbols, the symbols would be automatically >>> embedded >>> into the schematic. >> >> Given that you can't edit an embedded symbol right now, I think this >> undesirable. Especially since I often find myself making wholesale >> alterations to a multi-sheet design by editing a symbol. AD5601 not >> available? Easy to switch to AD5621 when your symbols are in a >> project directory, harder when they're embedded. And in ASIC design, >> I'm often tinkering with the building blocks. There, a stale symbol >> could be big trouble. >> >> I'm notorious for getting pin numbers wrong. Easy to fix with >> referenced symbols, not so easy with embedded. >> > > This is from my idea of only having a single copy of the symbol > embedded which > is referenced by one or more instances. > > When you update one instance, you update them all. >
What if your design has many pages? In my AD5601 example, there were many of these spread over a number of pages. What about projects that contain several boards built from a common parts stock? What about subsystems shared between projects? Projects fork and/or merge. They contain things other than circuits: software, test data, documentation, ... Given that a modern computer system comes with very flexible and powerful mechanisms to manage files, I find it extremely convenient to "factor" projects into small files. Manage them with a revision control system. Build products (netlists, docs, microcode, etc.) with Makefiles. Refactor, fork, and merge largely by moving and customizing files. Perhaps for a single project on a single page, the embedded approach is better. But I have a web of related projects, some very complex. That gEDA's extreme flexibility makes this manageable is a strong reason to use gEDA. Please don't compromise that flexibility. 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
