Practical advice on sharing custom symbol and footprint libraries in K8?

I’m looking for advice concerning logistics and process for sharing custom symbol and footprint libraries. The scenario I’m interested in is as follows:

  • A small number of collaborating Schematics and PCB designers (say 3)

  • in different geographic locations (so sharing via live connection to LAN fileserver is not feasible)

  • We don’t work on the same schematic/PCBs, but we do work with the same collection of components, and consequently can (and should) share libraries, and the development of those libraries.

We can’t sit down and create all library symbols and footprints ahead of time, and expect to develop needed custom symbols and footprints as we go along (as we normally would if working alone).

We can certainly follow a mutually-agree set of standards for these symbols and footprints (using much of KLC), and we have an agreed naming scheme.

So the main questions relate to

  • The mechanism and process for sharing the library components that we each developed, and one way or another, merge each others contributions into our local libraries.

  • Versioning of those components

  • Is this sharing scenario helped at all by database-based libraries?

I have read some suggestions from prior years, but these were from the time when Kicad did not used to store symbols and footprints in the schematic and PCB files, making such files more dependent on libraries, which I think constrained what you could do with the library files. Perhaps K7 and K8 afford more flexibility.

Some suggestions revolve around using git, and a git server such as github etc. That would require climbing the git learning curve, as these designers, not being software developers, are not already up-to-speed on the merits and idiosyncrasies of git. But in addition, even though the symbol and footprint library files are in a nominally text format, it’s not clear to me that git’s merging paradigm is particularly helpful. (And I realize that symbol libraries can have many symbols per library, whereas footprints are one per file – but I have not divined the implications.)

So I would be interested to hear thoughts and experiences on this, in light of current Kicad.

There is no version control / sharing functionality built into KiCad. An easy to understand, but cumbersome and error prone way is to zip up the library and mail them to each other. (Or, appoint one person as the library manager, and send changed symbols / footprints to that person).

But GIT is probably still the way to go. It does have it’s own learning curve, but you only have to know a very small part of GIT. there are also GUI’s built around git in which you can do the common tasks with a few mouse clicks.

1 Like

As paul has said, Git is the way to go. Even if 2 people add 2 different symbols to the same library at the same time it will merge them together. And keep track of who added what.
If you don’t want to mess with the command interface and setting up your own server, set up a private repository on github or gitlab to check it out. Github also has a client that is very easy to use. I personally use Github and it’s desktop client, but my library is public.

1 Like

Thanks @paulvdh for your comments, which add weight to using git.

Do you have experience with how well git merge works for libraries with multiple symbols?

Also, I have added to my original post a question as to whether database-based libraries help this scenario.

Thanks @Dawid_Cislo , you too have added to the recommendations for git.

Do you have experience with how well merge works for symbol libraries with multiple symbols per library?

Also, I have added to my original post a question as to whether database-based libraries help this scenario.

We use git for library distribution and versioning.

As our library is based upon KiCad’s official library this makes it possible to merge KiCad’s library changes. Footprints and 3D models are easy, while symbols sometimes require manual merging. But it is mostly easy.

1 Like

From my experience If you have changes to separate libraries, just pull right before commiting and it should merge automatically. KiCad libraries are text files, so you can see the changes highlighted in the client (if you use one) and you can select which sections to keep, and which ones to discard.
I have no notable experience of working with multiple people (because I’ve had like one actual commit form someone that’s not me so far) and that’s where my experience ends.
Github docs - collaborative coding section - might be a good (even if a bit overwhelming at first) resource:

1 Like