Centralized (global) library setup
Why would you use a global setup?
The benefit of global libraries is that this type of setup scales very well with the number of managed projects and library assets. It is especially well suited for collaboration within a relatively stable team (example within a company). This includes sharing projects between different computers owned by you.
In this case the one time effort required by every user to set up the central (global) library pays of during the prolonged time of working together.
How to get Libraries to Everyone in the Team
This first time setup consists of ensuring that the libraries are available to the current computers file system (details depend on file sharing option) After that the library tables need to be set up and if used also path variables set. See Library management in KiCad version 5 for details.
The libraries themselves can live on a normal file server which is mounted in the usual way. Another option is to use cloud services for exchanging the libs. But possibly the best option is to have the libraries in some sort of version control (example git or svn). Be aware that merging library changes requires at least some basic understanding of the file format. So svn with locks is a good option or using a pull request based system for git (gitlab, bitbucket or similar).
Manage what can get into the Central Library
It is beneficial if there are clear rules about library organization and asset design. Maybe even a review process that reduces the chances of an error for library assets before they are used in a project.
Continuous integration tools can help with the review process. Especially to check some common rules are followed (like a specific set of symbol fields that need to be filled for consistent BOM creation.)
As an inspiration take a look at the tools used by the official library team: https://github.com/KiCad/kicad-library-utils (symbol check scripts are in the
schlib subdirectory and footprint check assets in the
Guide to the First Time Setup
This guide is meant to be a template for your own personal guide that you share with your team (it is a shortened version of the above)
- Get the central lib onto your computer (git clone, svn checkout, mount network drive)
- Setup path variables (in KiCad) pointing to this storage location as required (at least for 3d models)
- Use the library managers (footprint and symbol) to add these libraries to your setup (to the global library table)
Simplify First Time Setup by Providing Library Tables
One can include the library tables for the shared libraries in some way to ease first time setup. It is suggested to use path variables for best results (otherwise all team members must place the libraries at the exact same file system path).
Sadly KiCad has no way to import a library table into an existing one. So one option is to include a full library table containing all libraries that are allowed to be used (So possibly including the official libraries in addition to your libraries).
This allows users to copy these tables directly in their KiCad config directory or if they never opened KiCad before use the first time setup dialog to point to this library table.
Another option is the use a text editor to copy the team entries into their tables. A saver option would be to develop a simple script that handles this task. Make sure no entries are duplicated by this step.
Centralized Library Tables
There is the option to directly link the user library tables to a central location. This will give the library team even more control over what assets can be used in projects.
A way to achieve this is to have a script that copies the library tables at a regular interval (example at login via the operating systems startup applications or as part of a custom KiCad startup script)
Another option is to point KiCads config directory into a config directory within the library location by setting the environment variable
KICAD_CONFIG_HOME as described in for example Running several KiCad versions on the same Windows machine. This really only works when using version control systems that allow excluding config files other than the lib tables.