In the DevOps playground of software development, designing and maintaining a native build automation process for a complex product over many years presents unique challenges. One topic which often gets over looked by product planning is upgrading compilers. The gritty work for ensuring the product maintains supported for existing platforms while offering access to new tools to developers to be innovative for a competitive edge.

Planning for this change is Toolchain Evolution.

Either maintaining old toolchains as new platforms arrive or a backport of toolchain on to an older platforms or any combination would satisfy the definitions.

There are two main forces driving teams to upgrade their toolchains, the first being security and the second also being security. The first is product security or "code safety", every year compilers and sanitizers are improving and offer new features that when utilized can detect buffer-overflow or free-after-use and prevent many vulnerabilities which are discovered. The second, less talked about, is corporate IT Security or "software supply chain security" where with native toolchains might be obsolete and pose a greater burden to maintain development.

Regardless which of these factors is motivating you, this post will explore the strategic considerations and operational challenges of managing a native build system for long-term success leveraging the concept of Toolchain Evolution during a product's lifecycle to help address both security needs.

The software development landscape is a nebulous. On one front, developers strive to craft innovative features at breakneck speed before requirements change. On another, security threats loom, constantly evolving to exploit vulnerabilities. In this environment, a robust and secure build process is no longer a luxury, it's a necessity as software supply chain attacks become more sophisticated.

This guide introduces the high-level designing a native C or C++ build process that prioritizes both speed and security.

Distributing the Build Work​

Imagine a factory with multiple assembly lines, each focused on a specific part of the product. This parallel approach increases efficiency and speeds up production. Similarly, in a build process, distributing work of various modules across multiple machines creates parallel build pipelines, leading to faster builds and improved scalability. This can be achieved through various means:

Have you ever stared longingly at that time-consuming progress bar, willing your C++ project to compile faster? If you're nodding along, you're not alone. The ISO's annual "lite" developer survey consistently reveals that over 60% of respondents consider long build times a major pain point, with little improvement year over year.

Thankfully, there's an old solution: distributing the build burden across multiple machines. This approach can dramatically slash those wait times (either way you go) and free you to focus on what matters - writing great code. This blog post will explore two prominent distribution techniques and how they've evolved: distributing compilation units and distributing targets. But here's the secret sauce: a target-based approach, the current best practice, can not only accelerate builds but also lead you to design cleaner and more maintainable build pipelines. Let's dive in!

C++ grants developers immense power, but with it comes the greater responsibility of managing memory. Memory leaks and access violations can bring down even the most robust applications. To combat these issues, sanitizers like AddressSanitizer (ASan) and LeakSanitizer (LSan) are invaluable tools. When it comes to addressing security, this is only the tip of the iceberg; you are expected to do more but sanitizers are an approachable starting pointing.

Despite these obvious upsides 50% of developers don't leverage these tools, integrating them into the build process often raises concerns about increased build times. This blog post explores a strategy to leverage modern build tools and parallelization to achieve exceptional memory safety without sacrificing CI speed.

In the ever-evolving world of C++, managing code effectively is paramount. Packages, a fundamental concept in software distribution, provide a structured approach to organizing and distributing reusable components. This blog post delves into the core elements of C++ packages, their essential properties, and how they streamline the development process and proposes a set of core concepts that should be captured by any specification.

The reason this is so important from a CI design point of view is creating an effective caching solution to help improve build times. Avoid uploading unnecessary files is an imperative requirement for this strategy.

As a C++ developer, ensuring your library integrates flawlessly with other projects is crucial for driving adoption. CMake being the defacto standard plays a vital role in this process by providing installed configuration files; guiding consumers on how to find and utilize your library using find_package. But how do you guarantee these config files are installed correctly and provide all the necessary information? Enter automated testing!

This blog post explores an approach for testing CMake config files inspired by Behavioral Driven Development practices and showcases a powerful implementation on GitHub Actions featuring 14+ test cases.

Why Test CMake Config Files?​

Imagine creating a fantastic C++ library, only to have users encounter missing headers or library paths when they attempt to integrate it within their builds. This very real headache is why many open-source developers have opted for header-only libraries. "Just copying the headers" eventually became the norm. However, this trend has culminated in ballooned build times, as the preprocessing stage can become a bottleneck.

It's that time of year once again! The ISO Committee published the summary of the results for the C++ Developer Survey "Lite". This has been running for several years and it's probably the first time we can start to see some trends... hopefully!

The survey results, with less than 1300 developers compared to 1700 last year, is only partially explained by third-party restrictions as noted by the blog post sharing the results. Regardless a wider sample would be ideal. The dominance of CMake with an 83% market share is striking. Could this 4% growth be linked to the lower burden for managing build scripts? Despite these limitations, the survey offers valuable insights into C++ ecosystem trends.

Since this blog is all about building and shipping C++ software, I'll be focusing on the tooling and ecosystem questions and results. There's a natural bias here, as I'm particularly interested in how these trends affect developers like us. But fear not, there's plenty for everyone! In fact, I'm curious what aspects other bloggers will delve into. Let's jump right in as there are some fascinating statistical correlations to explore!

Let's face it, in the land of C++ development, package management and reproducible builds can feel like oil and water. Package managers promise lightning-fast builds with pre-built libraries, while reproducible builds preach control and consistency by rebuilding everything. But here's the thing: they're not sworn enemies.

Think of it this way.

Let's start with the basic build system. Imagine you're spending hours compiling your code. You throw more cores at the problem, and the build time shrinks – but there's a limit. Eventually, adding more cores won't magically make it compile any faster. Now imagine you don't build at all. Poof! Your build time is divided by zero, because it's not happening at all, it's just not a factor anymore. The most reproducible builds are the ones you don't have to repeat endlessly. That's where package management comes in, saving you from endless build marathons. Yet there's even more benefits for reproducibility as well.

This post will explore how these two seemingly opposing forces can actually work together to create a streamlined and efficient development workflow. Despite being a new idea, there is evidence of this already being used along with potential new opportunities for future development in this space.

In the ever-evolving world of software development, ensuring code quality and maintainability is paramount. Two seemingly unrelated concepts, const correctness in C++ and ephemeral build environments from DevOps, share a surprising connection, both aiming to build a strong foundation for reliable software.

Const Correctness: Enforcing Immutability in Code​

Const correctness is a programming paradigm in C++ that emphasizes the use of the const keyword to explicitly declare variables and objects that shouldn't be modified. This enforces a form of immutability within your code. Just like an immutable object in other languages, a const variable cannot have its value changed after initialization.

The most relevant problems for C++ developers are package management, setting up CI/CD pipelines, and maintaining build scripts. Talking to developers and builds teams the cause of that frustration is the lack of interoperability between build systems.

The Common Package Specification (CPS) aims to revolutionize C++ development by standardizing how dependencies are described. While the core concept holds promise, specific aspects raise questions about its practicality within the C++ ecosystem.