On May 25, 2011, at 3:38 PM, DJ Delorie wrote: > * gnetlist needs the most work. It needs to be able to read a set of > rules, query the database, and fill in additional attributes based > on the rules. This need not be more than just "fill in the blanks" > for now.
The fundamental problem here is that gnetlist is designed to deliver certain digests of the design data to the back end. Most of this behavior is "hard-wired" in the gnetlist front end. The little prototype plug-in I posted for mapping package attributes works by intercepting the delivery of the digested data, but that's not a reasonable option for other attributes. So, a prerequisite here is refactoring to remove much of the hard-wired behavior from the gnetlist front end. We need to allow plug-ins to reasonably access all of the data from the schematics, not just the digests (although of course we should keep the digests, too: they're very useful). Once we have that, reading rules is pretty easy: I have already prototyped one representation. But if you start from the top-down, demanding that gnetlist support database access as a built-in "feature", it will be a very big job indeed. I don't think it can ever be done in a satisfactory way from that direction. Refactoring could also enable plug-ins to implement some other things I believe you'd like, such as electrically significant busses. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
