Stephan Boettcher wrote: > Remotely related to this topic, I had this idea: > > Often, there are several choices for footprint, model, whatever > attribute that need to to chosen at some point in the flow. We have proposals > for a kind of database to support the options. >
I envision a directory hiearchy of symbol definition, component definition, and footprint definition files, and the tool sweeps them at startup and then builds an in-memory database with sqlite to manage them at runtime. Or something like that. Keeping the data primitives separated until the last minute would make external scripting easier and more consistent, I think, especially if we offered a set of libraries to help with the common activities like understanding relationships between symbols, components, packages and footprints that all the various tools in a workflow (and custom workflows) could share. b.g. -- Bill Gatliff [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
