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 <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
