I disagree with the premise that there aren't a lot of similar things to worry about.
I've been designing with FPGAs recently. A given part often comes in several different packages with different pin numbering. Some of the parts have hundreds of pins, so it's usually necessary to break the part up into sections so the amount of stuff that is on one page is manageable. There are several plausible ways to break them up, and different people are likely to choose different rollups depending on how they choose to organize their overall design (for example, you could put the power/ground pins for a given bank on the symbol for the bank, or you could group all the powers and grounds together and put them all on the same page). On top of that, many parts these days have multifunction pins, leading to a desire to name the pins according to their actual use, for readability. And if you care about design rule checking, for production designs you will probably want to make variant symbols in which some of the configurable pins have their I/O direction and type specified according to the use in the design. And then, you have to deal with the fact that parts continually evolve, often sprouting extra functions on hitherto-unused pins. As a mundane example, the existing KiCAD libraries already have several different symbols for the PCI bus connector, with variations around 5V vs. 3.3V and 32 bits vs. 64 bits. And that's an easy case compared to FPGAs. Standard part families like the 74xx series are barely even interesting these days, so making any decisions based on their characteristics is the wrong optimization. I have been involved with CAD systems over a span of 25 years, in the roles of hardware designer, CAD software developer/maintainer, and library maintainer. My experience has been that library maintenance, while it may appear to be a trivial issue, is really the hardest part, because it is a moving target. Every part manufacturer in the world moves the target in many different directions by continuously coming out with new parts and new packages. This is why I think that building CAD libraries on a powerful substrate is the way to go. A file system hierarchy does not address the metadata problem, except by asserting that the problem is so trivial that the hierarchy itself constitutes all the metadata you need. You could invent some way to store metadata in files, but by the time that you have really addressed all the issues, what you will have done is reinvented the database. ------------------------ Yahoo! Groups Sponsor --------------------~--> See what's inside the new Yahoo! Groups email. http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/W4wwlB/TM --------------------------------------------------------------------~-> Please read the Kicad FAQ in the group files section before posting your question. Please post your bug reports here. They will be picked up by the creator of Kicad. Please contribute your symbols/modules to the library folder in the group files section. For building Kicad from source and other development questions visit the kicad-devel group at http://groups.yahoo.com/group/kicad-devel Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/kicad-users/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
