kicad-developers team mailing list archive

[Oliver Walters <oliver.henry.walters@xxxxxxxxx>]

Wayne,

Thanks for the clarification - this discussion is getting a bit sidetracked
I feel.

We will operate under the assumption that the footprints will be in a
single repo, without using submodules.

Any tools that can or will be developed for managing KiCad libraries are a
secondary requirement at this point.

Cheers,

Oliver

On Sat, Oct 7, 2017 at 12:20 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
wrote:

> On 10/6/2017 5:43 AM, Rene Pöschl wrote:
> > On 02/10/17 11:37, Simon Küppers wrote:
> >> I am no expert, but this question is out of the scope of this thread..
> >> For downloading, gut applies compression anyway.
> >>
> >> I respect the people having slow Internet lines.. However as shown a
> >> few posts backwards, the whole footprints and symbol library is like
> >> 100 megabytes without the 3d models. If think the benefit of a single
> >> repo outways the ability to download only a selection of libraries...
> >> By a LOT.
> >>
> > I agree with you here. Lets ignore the 3d model stuff and get back
> > talking about the footprint libs.
> > We are planning a massive library reorganization. (for the v5 release)
> > This will require a lot more footprint libs. If all these new libs are
> > all in a separate repo then this can not be done!
> > In addition to the new repos the old once still need to exist (and have
> > at least one footprint each) because otherwise the github plugin will
> > stop working for everyone who has this old repo in their fp-lib-table.
> >
> > **We library managers require whatever lib distribution is used to
> > support one repo that holds all footprint libs.** (one repo that has the
> > pretty folders as subdirectorys)
> > To be honest i do not care what will be used as long as this requirement
> > is fulfilled.
> >
> > We would really need a decision soon. Are you guys prepared to help us
> > out here such that we can move on with the lib reorganization? (The
> > details of how you do it can be discussed later.)
> >
>
> I thought I already addressed this issue but I will reiterate.  I am
> fine with the footprint library reorganization as long as the existing
> footprint library repos remain in tact for existing users.  These
> libraries do not need to be updated but we cannot remove them.  The
> other thing that will have to happen is that our package devs will have
> to buy into packaging the new footprint library repo as part of the
> install packages.  We will have to agree on an install path (
> ${CMAKE_INSTALL_PREFIX}/share/kicad/footprints seems logical) and make
> the default fp-lib-table file use the local install path with the KiCad
> plugin instead of the github plugin fp-lib-table.  I don't think this
> will be a major issue.  Does anyone have any major objections to this?
> If not, we will make this part of the stable 5 release.
>
> Cheers,
>
> Wayne
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>