15 docs tagged with "build"

Boost.Build is Boost's own build system — the toolchain Boost uses to compile itself. Its driver

Choosing a build system for firmware feels like a taste question and is not. The real question underneath it is who owns the generated code, and it has consequences that outlive the project: whether a colleague can build your firmware without installing an IDE, whether CI can build it at all, and whether the day you need to change a pin assignment costs ten minutes or a merge conflict across forty files you did not write.

The C++ compilation process transforms source code into executable binary through four main stages: preprocessing, compilation, assembly, and linking.

For a hobby project the toolchain question is nearly free: install Arm GNU, move on. For a product it is one of the longest-lived decisions in the codebase. A toolchain choice outlives the engineers who made it, because the compiler is baked into every build artefact you have ever released and into every certification argument you have ever made. Changing it later is not a flag change; it is a re-qualification.

CMake's defaults encode one assumption so deeply that it is easy to miss: the machine running the build can also run what the build produces. That is what lets CMake test a compiler by compiling and linking a tiny program, what lets findpackage look in /usr/lib, and what lets checkcsourceruns exist at all. Every one of those assumptions is false for a Cortex-M4 with 128 KB of RAM and no operating system.

A runtime level check is cheap, but it isn't free — it's still a branch and, on the disabled path,

Cross-compilation builds executables for a different platform (target) than the one running the compiler (host). Essential for embedded systems, mobile development, and deploying to different architectures.

One of the first practical questions every Boost user hits is: do I need to link anything? The answer

fmt's runtime cost is settled — it's fast, and that doesn't change based on how you build it. Its

fmt can be dropped into a project as header-only, with no build step at all, or built and linked as

There isn't one right way to add nlohmann/json to a project — there's a spectrum from "copy one

The header-only default is what makes spdlog trivial to adopt — copy a directory, add an include

There is no single "install Boost" button, and that is mostly fine: because the majority of Boost is

Makefiles define rules for building projects using the Make build system. They specify dependencies and commands to compile source code incrementally.

Modules are C++20's replacement for the textual #include model. Instead of the preprocessor