KiCad 7 Build Environment
Categories:
KiCad 7 has some notable improvements, not least among these is the addition of kicad-cli. Check out the Hackaday article for more.
Why a Build Environment?
I am a bit obsessed with pragmatic approaches to building and designing electronics. I want the complexity to not scale linearly in the number of projects I support. With shared design practices, reused sections, and update strategies log(n) complexity should be obtainable.
Setting up every projects in a similar way allows all sorts of automation. This helps reduce the entropy that naturally creeps into hardware projects. Keeping a consistent directory structure keeps down the number of variables in a project. Using a makefile to ensure consistent naming, settings/options, and directory structures are used is a great help in this struggle against the flood of complexity that hardware projects bring.
Project Structure & Versioning
One of the foundations of my workflow is semantic versioning for hardware. Part of a good build strategy is versioning, which allows a logical directory structure to develop in your version control software. A typical project might look like:
design/
├── 1.0.X/
│ ├── design.kicad_pro
│ ├── design.kicad_sch
│ ├── design.kicad_pcb
│ ├── 1.0.0/
│ │ ├── assembly/
│ │ │ ├── gerbers/
│ │ │ └── bom/
│ │ └── ...
└── 1.1.0/
This isn’t a hard requirement but I’ve found it incredibly useful.
I’m expecting to add to this makefile adding ‘bumpers’ helping ensure that all the files I need for a manufacturing run are up to date and correctly set up. All in the name of removing the possibility of entropy buildup and errors at the last stage of development. Getting boards in after 3 weeks that have 25 of the wrong component on each is not a good feeling.
If you’re building a KiCad automation flow or care about stress-free manufacturing, check out the repo and adapt it to your own needs. PRs welcome!