I recently had the itch to work on setting up a better template system or in this case repo for doing a lot of my C development work.

This Post is the result of a couple of hours hacking together the features I find most useful into a single place.

TLDR; Check out the repo here: ULTIMATE_C_TEMPLATE

Requirements⌗

So what makes me more efficient when working on C code? What allows me to write better code faster?

  • Has a LSP server available.
  • Tracks the source changes over time.
  • automates the repetitive stuff.
  • Test harness as part of the repo.
  • Adding new modules is fast.
  • Can handle multiple OSs
  • Can build for multiple targets.
  • checks for common errors.
  • Tuned for safety standards
  • Generates documentation.

Parts⌗

The Build System⌗

CMake

The build system selected is CMake. It’s well known, maintained and allows using toolchain files which make re-targeting easy.

It can also help reduce build times with other kinds of make systems like ninja, make, qmake, gmake, pmake etc.

The LSP⌗

Clangd

I could write an entire book on my love of clangd as an LSP.

It’s your auto complete on steroids. It’s the guiding light before your last edit at 3AM in the morning when the client needs the software ASAP.

Automation⌗

SH

When I say shell script most people think of bash or zsh or maybe even fish. But being the somewhat stubborn individual I am I try to maintain POSIX compliance with all my shell scripts.

It may or may not have to do with me using FreeBSD where the default shell is sh or csh.

Things to automate:⌗

  • Adding new modules/drivers
  • Auto adding new modules to vcs.
  • removing modules/drivers
  • running tests
  • building for another target
  • Installing needed dependencies
  • Isolating system wide changes.
  • Adding new taregt’s
  • Adding new toolchain files.

This list is continuously evolving; as I learn new concepts/tools and methodologies for code creation.

Multitarget⌗

For embedded use specifically often you’ll find you need to use a separate toolchain. For instance when I’m writing firmware for an STM32 I need to use an entirely separate toolchain.

This also happens when working with AVR, ESP and WCH firmware development.

To handle the need to build or cross-compile the code it’s added into our shell scripts, where some sed/awk magic can customize template files to generate the needed toolchain files.

Version Control⌗

GIT

There isn’t a whole lot to say on this front. GIT is pretty much the gold standard at the moment for version control.

NIX

I can almost hear someone yelling at me that NIX isn’t a VCS….they aren’t wrong.

But it’s semi-tangential to version control.

This lets us manage dependencies of the project’s code itself without cluttering the development system with them.

Documentation Generation⌗

This one was a bit harder to decide on. Doxygen, natural docs, cdoc

I ended up choosing to use Doxygen, it supports multiple languages, can build RTF, HTML and LaTeX as output.

It’s also well documented which is a hilarious problem for a documentation generation tool to have, but it’s not as uncommon as you would hope.

Part 2: Part2