← Back to team overview

kicad-developers team mailing list archive

Re: Library Repository


Vesa Solonen wrote:
Dick Hollenbeck kirjoitti:

phinitnan_c wrote:


I've created a set of library/package/3d and would like to share with

the group. How can i do that? I also think that it would be good if
there is a center repository for the library and make the lirary easier
to share.

My guess is that we all like to get this sorted, but I'm going to try
persuade everyone to wait a bit. Why? Because the infrastructure is not
ready yet. Current library system is IMO too limited for multiple
reasons and I have to make a document similar to Dick's
notes_about_pcbnew_new_file_format.odt found in KiCad SVN root, but
regarding symbol-component library.

Most of all, we haven't yet agreed on symbol styling and naming rules.
I've done some proposals about the style and they were generally
accepted (no strong opposition, so I take them accepted...). Feel free
to correct. Footprint naming was discussed some time ago, but decisions
were left somewhat open.

Vesa & Jean-Pierre,

I am happy to use the term 'footprint'. That says something. A certain amount on consistency on choice of nouns will make these conversations easier to follow.

As I said before, I hope to contribute a footprint retrieval plugin architecture starting in March/April time frame.

What might fall out of that, hopefully, is the ability to have a globally unique identifier for a footprint. I am not talking about eeschema symbols here. The globally unique footprint identifier will consist of various parts, TBD. But we could imagine that we might need to include what follows.

Generally what I am thinking is, WRT a globally unique footprint identifier, that it would have at least these fields in the identifier:

A) plugin name,
B) library locator (syntax could be plugin defined)
C) footprint name
D) revision

A concatenation of the above fields with syntactical separators, could then yield a single string which could be used to find a footprint anywhere in the world, at least if connected to the internet.

I have no interest in dictating anything here, especially not C). Actually I don't even want to be involved with C). But when you talk about "footprint names", I at least want to give you a sense of what that context is, down the road, just C).

Once you have a globally unique footprint identifier, then it will be possible to make associations from your EESCHEMA symbols to the footprints. AND folks will be able to have their own footprint libraries, as long as they can provide a plugin that offers access to them, privately or publicly. The entire notion of a central or master footprint library is probably obsolete at that point. There can be a "Kicad project team maintained" footprint library, but I expect there to be any number of other footprint libraries. Some from part vendors, others purely commercial and non-free.

We will likely need an internet based registry for the combination of A) and B).

Then the footprint plugin retrieval API will provide some simple directory (i.e. search) services once a pointer is established to the combination of A) & B)

I really don't have an interest in personally doing work beyond this, namely to the eeschema symbol infrastructure, but I do hope that some of the footprint retrieval API and plug-in architecture could be reused and refined for that end, once the power and use cases are all better understood.

I do not want to hold up my work trying to munge together footprints and eeschema symbols. That munging needs to happen on the symbol end, not the footprint end. I am biting off what I can swallow, not more, do don't start talking about how the footprint library needs to have symbols in it. That is beyond my commitment.

Others can come in later and extend it.

If this is all an obvious waste of time, let me know. Otherwise, you'll see more from me in March/April on it.


I'm sure you understand that we cannot allow just anyone to slam stuff
into the master library repo. Such a thing does exist on SVN, and Vesa
has been the maintainer of it. If you want stuff merged, send them to him.

The maintainer seems a bit too honorable to me as I haven't yet written
_anything_ to that repo :) JP did the last addition, but I'm willing to
take the library lead if we reach consensus that I have enough
credibility to be the benevolent dictator there. I think "newlib"
directory gets added for that.

Vesa if you don't want this hat, maybe its time to start recruiting
help. We're going to have to have more defined roles to grow this
project without chaos. I like that you stepped up and volunteered to
wear a specific hat.

I'm very happy to get a defined role as a project librarian, no doubts
about it. Something to consider before a real library rework includes at
least following:

* Implementing one symbol to multiple component mapping

* Implementing pin and gate swapping

* Logical to electrical to physical mapping
some components don't have logical or electrical polarity, but only
physical (variable capacitor)

* Everything must be abstracted as much as possible to get flexibilty
and ease of use and maintenance.

* Is my style proposal good enough

None of the above is not going to be fun or fast and I very probably end
up being quite punctual regarding "libarary standards" because someones
work depends on it (me included). That may also upset someone, but it
won't be my intention. Be assured that I'll do my best to sort those
possible upsets.

So in the end phinitnan_c, I'm very willing to work with you on this.