← Back to team overview

kicad-developers team mailing list archive

Re: Github part footprint filenames


On Wed, Aug 21, 2013 at 10:14:04AM -0400, Chris Morgan wrote:
> - Using the filename to build the footprint name sounds like a great idea.

Also the sanest one, IMHO

> - Lorenzo, your writeup is good and you should put that up on a kicad
> wiki somewhere. I'd feel bad if your write up wasn't used elsewhere as
> I was referring to names in a more generic sense. Let me provide a few
> concrete examples that maybe we can discuss around.

No idea if such a wiki does exist. These are my current working
(production) practices, anyway, so at least they are tested:D

> - Use case 1. Github repository used directly
> -- Directory hierarchy might indicate the part family (connectors vs.
> ICs vs. displays etc), or not.

Usual library taxonomy. If it should be organized by manufacturer or
component is a logistic issue; IIRC Eagle is manufacturer-rooted, but
that is not necessarily the best way to handle it.

> -- Because this is a filesystem we can't have more than one footprint
> in a given directory with a given name. If we wanted to have more than

A rule like 'no same named footprint per library' is reasonable.
Precedence between libraries is AFAIK one of the reason for the new fp
table (I think).

> --- Different file names

Good luck with that. I think that the library should be organized by the
'owner' of the library. If you don't like my part use one from another
lib. So maybe, same name, different library would be a better idea
(think about a branched repository)

> --- Ability to look into the footprint git history. I'm not sure this
> is a valuable approach.

Especially considering the format of a git 'revision'. Also what if it
need to be updated?

> - Use case 2. Web site generated repository

Do you mean a site creating a view on the underlying footprint database?

> -- Directory hierarchy might indicate part family. Might also reflect
> the maturity of the parts, /stable vs. /unstable directories etc. This
> can be pretty dynamic.

Debian package archive:D you just described that!

> -- We should expect that as-of-yet unknown requirements will dictate a
> dynamically generated format that we didn't anticipate so we want to
> at least consider that there might be really odd dynamic layouts
> generated.

May be useful at least for searching stuff.

> I'm not sure if the dynamically generated repository is going to be a
> big issue on the kicad side or not.

>From the kicad side I see only requesting URLs somewhere. If that
somewhere gives a static list file or something CGI built I don't see what
would matter for it. Want to get a package? just

GET http://library.kicad.org/packages/WONDER-PACKAGE

and it should spit down the sexp for the package. Searching would happen
querying an 'appropriate' URL.

Lorenzo Marcantonio
Logos Srl

Follow ups