kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@...>]

2009/11/13 Wayne Stambaugh <stambaughw@...>:
> Brian,
>
> Thanks for the explanation of heavy versus light libraries.  I wasn't
> getting this (I'm a little slow sometimes) from some of the previous
> posts.  The weakness I see in this is if for any reason your had to
> change the base component symbols, you would have to update the entire
> library as opposed just changing the library root component.  Also the
> libraries could become huge (potentially 10s of thousands of parts for
> resistor and capacitor libraries) which would significantly impact
> performance and memory use.  You have also effectively made field 5 a
> part number field which may not work for everyone else.  You solution
> sounds like it is better suited for creating user specific component
> information as opposed to a robust set of component libraries that would
> ship with Kicad.  I understand what it is you are trying to accomplish.

Hi Wayne,

I failed to mention the fact that I would intend a true heavy symbol
implimentation to be accomplished with one component that is then
aliased. I didn't realise that the aliases are in the dcm file as
Jean-Pierre mentions in his next email. I'll reply to that and perhaps
I can get a workload together. Hopefully the changes will not need to
be too deep.

Field 5 is something I can use for whatever purpose as anyone can. I
am not proposing that KiCad itself move over to a heavy symbol library
or even be bundled with one, just that it provides the ability to have
one. I'm also not trying to suggest a new symbol library format per
sae; that is the subject of another discussion.

>  I have the same problems when I create BOMs.  I am just not sure that
> this is the best way to attack the problem.  Maybe this is where some
> type of database implementation would be useful that some of the other
> developers have suggested.  That way all your local information, part
> numbers, manufacturers, vendors, cost, etc. would be independent of the
> actual component libraries themselves.  If you could separate it out
> that way or by some other method, it would probably be easier for other
> to accept.

There is a seperate discussion about the pro's and con's of different
types of implimentations for symbol libraries and it looks like people
have some great ideas and lots of opinions. I don't really want to
escalate to that arena. I feel that a little tickling of the code
could help initially support a heavy system with what KiCad has
available right now, probably with a few warts, but the ability to
support something is better than not.

Best Regards,

Brian.