kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 9/24/2010 2:25 AM, Lorenzo Marcantonio wrote:
> On Thu, 23 Sep 2010, Dick Hollenbeck wrote:
> 
>> Inheritance.  hmmm.  Why not just *copy* symbol by symbol and make each
>> copied symbol into a part-specific component in a new project specific
>> library.
> 
> I agree. More simple to use and less complex to implement, can't be
> a bad thing :D
> 
>> But we are moving in the right direction by really thinking about what
>> we do.   The heavy library is a wish, I don't think anybody will ever be
>> able to keep up with the new stuff hitting the market.  It is way too
> 
> It simply can't exist, not even the big vendor can do this (well, maybe
> a vendor which lives selling libraries). And anyway (excluding stuff
> with more than 80 pins) you draw a part in 15 minutes when you need it.
> 
> Given the 'thinking time' I need to properly use some component, drawing
> the symbol is a small period of time (exercise: design a power supply
> and tell me what % of the time you lost drawing the switcher IC:D)
> 
> For footprints (packages) that's another thing, but, excluding some
> exotic component (like DirectFETs and PowerSOs) these are JEDECed anyway
> and can be dynamically generated.
> 
>> A simpler set of ambitions/goals is to simply get the parts correct that
>> you intend to use on a specific board.  And I even struggle with that.
> 
> I'm curious, why are you struggling?
> 
>> Is there any value in having a project specific library that is more
>> tightly bound to the project?  Or is a personal library good enough?  I
> 
> For me no... When I need a component that's not already in a library
> I simply draw it and put in the right system library. So in the next
> board I can use it: I never encountered a component *only* for a board,
> and since my assembly facility have to stock it for production it's
> better to reuse it for the next projects too, if possible.
> 
>> actually think it might be worth discussing putting a project specific
>> library *within* the project, say for example within the schematic.
>> This fully embraces the use case behavior.  It also centralizes the
>> place where you might fill in the things needed to make a good BOM.
>> Each unique part is in there, and then each unique part can be
>> instantiated from there into the schematic and it's reference designator
>> changed, nothing more.
> 
> Technically there would be no need for 'libraries' since anyway they're
> searched in order. You could just build a big database with *all* the
> stuff inside (and a good search facility): that's what orcad's CIM does
> IIRC. Libraries are for browsing, not searching IMHO.

I'm not particularly thrilled by the idea of using a database.  There are the
issues of which database(s) would (should) we support MySQL, PostgreSQL, DB2,
Oracle, etc.) and the added project dependencies.  The library search order
issue is going to be fixed.  I am adding logical name support to the new
library file format making it possible to locate a component based on it's
logical name and value field name pair.  This will resolve the long standing
issue with library ordering when components with the same name exist in
multiple libraries.  Granted this won't be completely fixed until we update the
schematic file format but the library file format has to be fixed first.

Wayne

>