Bill Gatliff <[email protected]> writes: > 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.
This is exactly what I did _not_ have in mind, at this point. And if such a database is implemented, it should be implemented on top of somthing simple like as I _had_ in mind. _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
