Understanding KiCad's code repositories

Hi developers, the intend of this thread is to help me, and hope others, to understanding the KiCad repositories and code organization. I know that KiCad have these base repositories:

Despite my understanding of these above mentioned repositories still a bunch of them that I can not complete understand or miss to understanding of the interaction in the project (e.g.: how packing process is made in the CI/CD and the function of KiCad Packaging · GitLab? How to check the answer for Simulator: lingering old directives? (#13955) · Issues · KiCad / KiCad Source Code / kicad · GitLab, is it into kicad-ubuntu-builder · GitLab).

Is there some docs of internal infrastructure of KiCad?

Hi Hildo-

The CI/CD processes do not provide packaging. The nightly builds run separate processes (kicad-mac-builder, kicad-win-builder, kicad-ubuntu-builder) from the CI images.

We don’t have a document atm showing how the various repositories relate. Our documentation is mostly in terms of how to run the builders and CI. These are necessarily not public as they include authentication information that the KiCad team needs to build and troubleshoot the various systems.

Thank, Seth_h.

So, may I understanding the packing process as triggers of CI/CD (to keep the keys and secrets out) of the scripts of repositories in


Why Ubuntu repository for packing have several sub repositories? It appears to have different compile procedure because of dependences (repository for Nighly, NGSpice, …), which is conceptually different of Fedora and Windows packing (single repository).

In general each distro or platform will chop up an application suite in different ways. For example a distro might already have a shared library for say libngspice and the package maintainer might decide to try to work with that instead of building their own and providing another shared library or bloating the binary by linking them statically. Sometimes the distro’s shared libraries are too old so the packager has to provide a newer version, e.g. like what was done for wx in Ubuntu.

It’s way the Ubuntu/debian works.
Each git repo represents a independent package to build. This gets fed to the automatic builder features of say launchpad to build one package. We build some dependencies like ngspice because debian and ubuntu release cycles are insanely hostile for desktop users and we would be plagued by people reporting bugs that we can’t fix as they are in the dependencies.

Fedora uses already built packages for dependencies because its usually far more up to date than Ubuntu so we only need to build kicad.

Windows is always built from scratch and completely freeform on how we want to build it :wink:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.