Kconfig system with CMake

This repository is a small training project that explains how a Zephyr-like configuration flow can be built from simple pieces.

It demonstrates how to connect:

• Kconfig language definitions
• menuconfig via kconfig-frontends
• CMake custom targets and commands
• Ninja as the build runner
• generated .config and autoconf.h outputs

The project is intentionally minimal. Its purpose is not to replace Zephyr, but to help understand the mechanics behind a Kconfig-driven embedded build flow.

Training goals

This repository is useful if you want to learn:

• what Kconfig does and what it does not do
• how menuconfig is launched from a build system
• how .config is turned into compile-time macros
• why Zephyr needs extra tooling around plain Kconfig
• how CMake can bridge configuration and compilation steps

What this project contains

Kconfig-System-with-CMake/
├── CMakeLists.txt
├── Kconfig
├── prj.conf
├── src/
│   └── main.c
└── cmake/
	└── kconfig.cmake

File overview

Kconfig

Defines the configuration symbols exposed to the user:

mainmenu "Demo Project Configuration"

config DEMO_FEATURE
	bool "Enable demo feature"
	default y

config DEMO_VALUE
	int "Demo integer value"
	default 42

In this demo:

• DEMO_FEATURE is a boolean switch
• DEMO_VALUE is an integer parameter

prj.conf

Provides the base project configuration used as the default input for Kconfig processing.

In the current version of this training project, prj.conf is effectively the authoritative configuration source for the build.

This is an important educational detail:

• menuconfig can modify the generated build/.config
• but the build step regenerates .config from prj.conf
• which means values defined in prj.conf win on the next rebuild

For example, if you change CONFIG_DEMO_VALUE to 50 in menuconfig, that value may appear in build/.config for a moment. However, once the project rebuilds, the current CMake flow regenerates .config from prj.conf, so the value returns to 45.

This behavior is intentional in this demo because it makes the configuration flow easier to understand: prj.conf acts as the stable project-level input, while .config is treated as a generated build artifact.

Current defaults:

CONFIG_DEMO_FEATURE=y
CONFIG_DEMO_VALUE=45

cmake/kconfig.cmake

Implements the glue layer between Kconfig and CMake:

• locates kconfig-conf and kconfig-mconf
• provides the menuconfig target
• generates .config
• generates include/autoconf.h

src/main.c

Consumes the generated configuration header at compile time and prints the selected values.

Prerequisites

This example was prepared for a Linux environment with kconfig-frontends installed.

On Ubuntu or Debian-based systems:

sudo apt install kconfig-frontends libncurses-dev cmake ninja-build

Required tools:

• cmake
• ninja
• kconfig-conf
• kconfig-mconf

Windows / MSYS2 note

If you are working on Windows, the simplest and most reliable setup is WSL with Ubuntu.

At the time of writing, standard MSYS2 repositories do not provide the Linux kconfig-frontends package with the kconfig-conf and kconfig-mconf tools used by this project. MSYS2 has packages named kconfig, but those refer to KDE KConfig and are not the same thing.

Practical recommendation:

• use Ubuntu or WSL Ubuntu for this repository
• treat the GitHub Actions workflow as the reference environment
• do not expect plain MSYS2 to provide a drop-in menuconfig setup for this example

Build workflow

Configure the build directory:

cmake -B build -G Ninja

Open the text UI:

ninja -C build menuconfig

Build the demo application:

ninja -C build

Run the executable:

./build/demo

Expected result

With the current default configuration, the program prints:

Feature enabled!
Value: 45

If you change the value in menuconfig, rebuild, and run again, the output should reflect the updated configuration.

How the flow works

1. Kconfig defines the available symbols.
2. prj.conf provides initial values.
3. kconfig-conf generates a build-local .config file.
4. kconfig-mconf provides the interactive menuconfig UI.
5. A custom CMake rule converts .config into build/include/autoconf.h.
6. The C program includes autoconf.h and uses the generated macros.

This mirrors the general idea used by Zephyr, but in a deliberately reduced form.

Generated artifacts

After configuration and build, the important generated files are:

build/
├── .config
└── include/
	└── autoconf.h

Why autoconf.h is generated manually

One important training point in this repository is that Ubuntu kconfig-frontends generates .config, but does not automatically generate autoconf.h in the way many users expect from Linux or Zephyr-based flows.

To close that gap, this project adds a simple conversion step in CMake.

Key lessons

• Kconfig is a configuration language, not a complete build system.
• menuconfig needs terminal support, which is why USES_TERMINAL matters in CMake.
• Zephyr adds extra tooling on top of raw Kconfig.
• Even a small example needs explicit glue between configuration output and compiler input.

Suggested training exercises

Try the following to understand the system better:

• disable DEMO_FEATURE in menuconfig and rebuild
• change DEMO_VALUE to a different integer and verify the runtime output
• inspect build/.config after saving in menuconfig
• inspect build/include/autoconf.h after rebuilding
• add a new Kconfig symbol and use it in src/main.c

Limitations

This demo keeps the implementation intentionally small. It does not try to cover:

• advanced type handling
• symbol dependencies
• choice blocks
• defconfig layering
• modular Kconfig trees
• Zephyr-specific helper scripts and generators

Relationship to Zephyr

This is not Zephyr code and not a drop-in replacement for the Zephyr build system.

It is a teaching example inspired by the same general ideas:

• configuration described in Kconfig files
• interactive configuration through menuconfig
• generated compile-time configuration headers
• build orchestration through CMake

License

Source code in this repository is licensed under the MIT License. See LICENSE.

If you publish an accompanying article or long-form documentation for this project, you can license the text separately under Creative Commons Attribution 4.0 International (CC BY 4.0). See ARTICLE-LICENSE.md for a ready-to-use note.