On Jul 28, 2009, at 1:52 PM, Kai-Martin Knaak wrote: > On Mon, 27 Jul 2009 11:36:53 -0600, John P. Doty wrote: > >> Anything that goes into a BOM, for example. That's an open ended >> list, > > ack. > > >> A one-shot solution for each attribute won't work. > > ack. > > >> Nor, I think, is it right to do >> this for all attributes, as "source" is potentially properly >> multiple, >> and we shouldn't preclude other such attributes. > > Almost all attributes should be made unique with regard to the refdes. > Therefore it is better to define a set exceptions. The information > which > attributes are exceptions must reside somewhere. Hard coded into the > source is clearly no good option.
Flexibly coded into the back ends is a good option. A typical PC layout netlister needs exactly one footprint per device at the end of the day. A typical BOM generator needs at most one value per column, and it knows what the columns are. Other flows, other back ends, other requirements. > Somewhere in the config files is an > invitation for inconsistency problems. It don't think it's a config file thing. > It would make a *.sch file even > less selfcontained. Well, I don't think of .sch files as self contained anyway. I treat them like source code: what they "compile" to depends on the environment in which they are "compiled" (netlisted). That makes it fairly easy to reuse them in projects with different parts stocks, for example. > You'd have to always ship a gnetrc along with > schematic file. > > So the information should be included in the schematic. That's a potential barrier to reuse. > It would be > possible to read gnetlist options from global attributes of the > schematic > or from attributes of the title page. However, I'd be wary to > introduce > yet another way to pass options to gaf applications. > > But how about this: > > Require, that every attribute is unique within the set of symbols with > the same refdes. Breaks the current usage of source=. Might break custom flows, too. > But add the notion of lists as values of an attribute. > Instead of multiple attributes there would be multiple values of an > attribute. As an aside, this would resolve possible ambiguity about > the > priority of attributes. A list is ordered in an intuitive way. An > additional benefit is, that the multiple values cannot be scattered > over > multiple symbols. This reduces the chance of confusion. > > Value lists would come handy with my other most wanted gschem feature, > too: Present a selection of reasonable footprints in the attribute > editor > of gschem. The list of reasonable footprints should be a property > of the > symbol and it should be adapted to the preferences of the site or > project. Well, that whole approach is incompatible with schematic reuse, at least the way I do it. In most cases it's more sensible to put the footprint in the project symbol, not attach it in the schematic. > > What would be a sensible syntax for lists of values? Scheme syntax. Then you can represent arbitrary data structures, and need not write another parser. The front end need not even understand this: the back end can trivially parse this with (read) without evaluation from a string port. > The attribute name should contain the information, that the > attribute can > contain a list. Else, simple string values might be misinterpreted > to be > lists. An intuitive way to mark an attribute as a list would be to > require "list_of_" at the start of the name. List items might be > separated by semicolons. > > Bottom line: I propose to make every attribute in a set of multi part > symbols unique during gnetlist runs. If more than one value of a > attribute is required for some purpose, this can be achieved with a > list > of values. > > Do you see a flaw in this approach? I generally worry about rigidification. But if the back end has access to all of the attributes, and can therefore choose to use these rules or bypass them, I see little harm here. But perhaps others have comments. There might be several ways to compose a particular device, and attributes with duplicate names might be useful in that case, but I can't think of an example. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
