On Tue, 28 Jul 2009 15:16:26 -0600, John Doty wrote: >> It would make a *.sch file even >> less selfcontained. > > Well, I don't think of .sch files as self contained anyway.
Others do. Different work-flows ... >> So the information should be included in the schematic. > > That's a potential barrier to reuse. Not, if the information is included via embedded symbols. (Yes, I know, you don't like embedding) >> Require, that every attribute is unique within the set of symbols with >> the same refdes. > > Breaks the current usage of source=. No. Attribute unification applies to the internal netlist after subsheet symbols have been resolved to whatever the subsheet contains. > Might break custom flows, too. Hardly. Current gnetlist already returns exactly one value for every attribute of a set of symbols with the same refdes. If more than one part of a multi part symbol contains the same attribute, gnetlist simply picks the first. The supposed requirement only removes the current uncertainty which attribute will be returned. > Well, that whole approach is incompatible with schematic reuse, at least > the way I do it. You can do everything exactly as you do now if you don't use list_of attributes. Even if you do, the proposed changes don't affect the schematic at all. It affects the symbols. > In most cases it's more sensible to put the footprint > in the project symbol, not attach it in the schematic. I don't propose to attach the footprint, or any other attribute anywhere else than to the symbols. >> What would be a sensible syntax for lists of values? > > Scheme syntax. scheme syntax in attribute values <frowns> > the back end can trivially parse this with (read) without > evaluation from a string port. And it will act in an intransparent, user unfriendly way in case of errors. Just like gschem already does, when it runs into problems with the config files. Silently failing to read the rest of the file made me e scratch at my head more than once. Generalized syntax comes at a price. > I see little harm here. :-) ---<(kaimartin)>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
