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.
Slow builds slow down the business, not just engineering. Ensuring enough priority is balanced with improving and evolving builds is critical to keeping up with changing requirements. Given the complexity and scale a one-size-fits-all build process is unlikely to succeed. Instead, a strategic approach that divides the work and optimizes for different types of builds is essential. These complicated distributed systems will be prime targets for threat actors - requiring IT security baseline to be up held to prevent being the weak line in a supply chain attack. This connection is directly pulled from the philosophy of DevOps.
Far to often this topic is over shadowed with making the code safe. "C++ Safety" and "Delivering Safe C++" have gotten a lot of attention, but both piece suggest, that is only part of a good Defense in Depth strategy. Back in 2023, an excellent report about C++ Standards Usage which highlighted the lack luster adoption of C++23... The 2024 C++ ISO Survey once again has 61% are "not allowed" to use C++23 along with 36% "not allowed" to use C++20. This sluggishness is not new, even if we invent a better more safe version of C++ it very well could take 10 years for it to be adopted by the industry.
This is why it's imperative to incorporate toolchain evolution into the product development roadmap.
Before diving into the details, let's establish some baseline assumptions:
A native build system is a software infrastructure designed to compile, link, and package code into executable programs or libraries specifically for a particular operating system and/or hardware platform. It operates directly within a target environment, utilizing the system's native tools, compilers, and dependencies to produce optimized, platform-specific binaries which may run on the same or different target platform.
With unlimited money and large workforces it's easier to practice a large philosophical design concepts for how products and developed can be released to costumers. Large tech companies are often easy examples to see what different variations exist.
Planning to innovate and adopt technologies is always a balancing act which comes at odds with supporting existing hardware. The combinatorics of platform support means inevitably old platforms will no longer be supported. There's will always be laggards and those systems will need to be moved on to newer platforms which might no be compatible.
Building into the build automation process to support both can be a huge advantage.
One strategy, that has been increasing in the spotlight thanks to large tech companies, for controlling toolchain evolution is to own the hardware design. By designing their own chips, companies can tailor the underlying architecture to their specific needs and ensure that the existing toolchain remains tightly integrated and provides greater control. Ensuring hardware support over the generations of the product allows for more predictable updates and support.
A notable example of this strategy is Google's decision to develop its own mobile processors for its Pixel smartphones. By designing these processors in-house, Google can ensure that they are optimized for its specific software requirements and that the toolchain remains tightly integrated. Furthermore, Google's commitment to providing seven years of security updates for its Pixel devices demonstrates its long-term focus on toolchain evolution and product support.
While owning the hardware design offers significant advantages for controlling toolchain evolution, it's not without drawbacks. The high upfront investment, increased complexity, and potential for delays can be significant hurdles for smaller companies. Additionally, custom hardware may not be suitable for all markets, and companies may face obsolescence down the line when committing to older technologies.
Another effective strategy for managing toolchain evolution is to maintain control over the toolchain itself. This involves developing or customizing the tools that allow access or control of the product and ensuring that the toolchain remains compatible. By controlling the toolchain, organizations can maintain greater flexibility in their product development process.
Apple's SDKs are an excellent example of this. By releasing it's own toolchain, Apple has gained greater control over what hardware configurations are supported, and by tying this into the operating systems release cycle. The Apple-clang compiler, which is specifically designed for Apple's tightly controlled architecture, provides a powerful and optimized tool for developing software for these platforms. This allows them to dictate what version of the toolchains are used and can plan to phase out older toolchains.
This strategy can be scaled up or down in some unique and useful ways. This will be the third post focusing on bringing older compilers to newer platforms with the aim of maintaining legacy code bases.
While maintaining control over the toolchain is important, it is also essential to stay on the cutting edge of technology. By adopting new tools and techniques as they emerge, organizations can improve product quality, reduce development time, and stay ahead of the competition. However, it is crucial to balance the benefits of adopting new technology with the risks associated with early adoption.
Facebook's approach to software development, which involves rebuilding its entire codebase (a monorepo) together, demonstrates a commitment to living on the bleeding edge. By continually modernizing its infrastructure and toolchain along with the code base, Facebook can take advantage of the latest advancements in technology and ensure that its products remain competitive. However, this approach also requires significant investment in infrastructure, testing, and risk management.
To achieve the best results, most organizations should consider a combined approach that incorporates all three strategies and variations of these ideas tweaked to meet their unique needs. Planning to maintain hardware compatibility, building your own toolchains and designing a solid build process, companies can create a robust and flexible product development ecosystem that supports long-term innovation and success. That is easier said then done. There are trade-offs at every corners and picking the write ones for your business are imperative.
Maintaining support for older hardware generations is offers a lot of incentive to customer, however eventually will not be feasible. Tesla is a fun example where they still offer updates for a 2012 Model S with upgrade infotainment systems but the 2023 Model 3 and Model Y may no longer receive updates for the long await "FSD" beta-program. Building the same code across many generations of hardware changes is no small feet.
Over time, several challenges will inevitably arise when managing a build system:
Supporting software on specific hardware platforms for five or more years presents a unique set of challenges. The tools you choose at the start of a project may not be supported on future versions of the operating system or may lack the necessary updates to remain viable as the security landscape evolves. The other side is also true, newer version of tools many stop support or become incompatible with older platforms preventing their adoptions. Aim to have support your own toolchains or work with vendors to ensure their support cycle is correctly aligned.
Successfully managing toolchain evolution requires a proactive and strategic approach. Build more configurations is the best default advice.
Toolchain evolution is not a one-size-fits-all solution, but rather a strategic dance between security, innovation, and practicality. By considering the various approaches – owning the hardware design, controlling the toolchain, or staying on the bleeding edge – organizations can craft a plan that best suits their needs. Understanding the long-term implications of hardware compatibility, technical debt, and knowledge transfer are all crucial components for building a robust build process.
Ultimately, a well-designed and well-maintained build system that embraces toolchain evolution is the cornerstone of long-term product success. It allows developers to innovate with the latest tools and technologies, while ensuring that the product remains secure and functional for existing hardware platforms. This delicate balance between legacy support and future-proofing is the key to building software that endures.
]]>This guide introduces the high-level designing a native C or C++ build process that prioritizes both speed and security.
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:
Services that provide this functionality are a dime as dozen, GitHub Enterprise, GitLab, or BitBucket Pipelines all lend themselves very well to this.
The biggest limiting factor will actually be your product software design. The order of which C or C++ code can be compiled, linked, or archived is a direct consequence of the design. Favoring microservices design patterns along with re-usable components are likely to lead to better build times.
Not all builds are equal, you'll want to consider different strategies for developer versus automation.
Not all software builds are equal. Understanding the difference between cold builds and incremental builds is key to optimizing your build strategy. Many of these ideas carry over from other aspect such as deployment or application start.
Balancing the frequency of cold and incremental builds is crucial. While incremental builds save time during development, regular cold builds should be scheduled to ensure that the build system remains reliable and that no hidden dependencies are introduced.
Build caching is a technique used to accelerate the software build process by storing and reusing previously generated build outputs. Instead of recompiling the entire codebase from scratch, a build cache stores intermediate compiler outputs—such as object files, libraries, or executables—so that only the changed components need to be rebuilt.
There are two key types of build caching:
Both types of caching are closely related to artifact management, where these cached outputs (artifacts) are stored, versioned, and retrieved efficiently. Proper build caching can dramatically speed up incremental builds and ensure consistency across different development environments.
To ensure that all individual contributions from your teams are cohesive, and that the final software package is ready for the release process, a robust CI/CD pipeline is essential.
CI is the practice of automatically integrating code changes from multiple contributors into the main branch frequently. Each integration is verified by an automated build and automated tests, which helps detect errors early.
CD is the practice of automatically deploying software that has passed the CI pipeline into production or a production-like environment. This ensures that the software is always in a deployable state.
In today's software landscape, security threats are constantly evolving not just for the product but also the critical IT infrastructure internally to the business - this includes the build process as Solarwinds proved, and this has a direct impact on the toolchain used to build and maintain your software. Security vulnerabilities in tool dependencies such as compilers, linkers, libraries, and even build scripts can become points of exploitation. System dependencies such as CI/CD Agents, Operating Systems and Security Agents themselves evolve to mitigate these threats, they often introduce changes that can render older tools obsolete or incompatible. This forces you to continuously update your dependencies, ensuring that everything remains secure and capable of producing reliable software.
By understanding the techniques outlined in this guide, you can elevate your native build process to new heights. This empowers you to achieve both speed and security, the cornerstones of a modern development environment. Understanding the nuances of cold, warm, and incremental builds equips you to choose the right approach for each situation. We've also unveiled the power of build caching, a technique that dramatically accelerates builds by reusing previously generated outputs. Mot importantly, implement security best practices. Regularly update your toolchain and enforce secure coding practices.
But remember, the journey doesn't stop there. In today's threat landscape, security is paramount. We've explored the ever-evolving security challenges that necessitate the continuous evolution of your build toolchain. Factors like operating system upgrades, hardware platform changes, and evolving security compliance requirements all demand a proactive approach to toolchain management.
By embracing the strategies outlined in this guide, you can establish a secure and efficient native build process for your C and C++ code. This empowers your team to deliver innovative software with confidence, knowing that your build process is both robust and resilient.
By following these steps and leveraging the knowledge from this guide, you can build a secure and efficient native build process that propels your software development efforts forward.
]]>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!
This strategy leverages C++'s compilation process, this strategy focuses on splitting the build into individual source files (compilation units) and compiling them into object files in parallel. Each machine receives a unit, compiles it independently, and returns the object file. This method is sometimes refered to as a task-based, where the order of the tasks needs to be preserved.
This approach has roots in the historical use of Makefiles for parallelizing builds. Makefiles, with their file-based structure, allowed developers to define separate targets for object, assembled, archived, linked and other build artifact files. By leveraging the make -j flag, builds could be spread across multiple cores or machines.
However, Makefiles faced limitations:
Both of these combine to limit the ability to perform incremental builds. This will cost all the developers to rebuild or "cold build" more often. As all the task need to be re-ran in the same order dividing the a sub graph pulls is more difficult.
Makefile's language of "targets" referred to compilation targets for instance going from a .c to a .o creating a dependency that could be tracked for a single linked target. These compilation unit themselves could be distributed with other strategies.
Despite the challenges with distributing tasks within Makefile, distributing compilation units can still be relevant for a variety of projects with few targets but could still benefit from incremental builds. Here are some tools that implement this strategy:
A crucial element for reducing redundant compilations is caching previously compiled object files based on the source code, compiler flags, and header versions. If a unit hasn't changed, the cached object file can be reused, significantly accelerating the build process. A very popular approach is combining it with ccache which has been deployed for a long while. these two tools are intended to be used at the compiler level, they can be drop in replacements that wrap the compiler. This ability can be very useful to combine with other other distribution models.
Modern build tools like Bazel address the challenges seen with distributing Makefile builds by emphasizing the target-level dependencies. This is the current best practice, this recent talk by CMake does a great job presenting this. Each target (library, executable, etc.) explicitly declares its dependencies on other targets. This allows the build system to intelligently determine the optimal build order and efficiently distribute tasks across machines. It's worth noting Bazel language for target's is artifacts, which much more closely aligns with DevOps' principal for artifact management.
Here's how Bazel, handles target-level dependencies:
.bzl file (Bazel's build language).cc_library.deps and cc_binary.deps.With a sample project, simply running bazel build json_formatter which correct order the targets and leverage all the resources in the local system.
# Define the application binary
cc_binary(
name = "json_formatter",
srcs = ["json_formatter.cpp"],
deps = [
# Dependencies for JSON parsing and formatting
"@com_github_nlohmann_json//:json", # nlohmann_json library
],
)
# Download nlohmann_json as an external repository
http_archive(
name = "com_github_nlohmann_json",
urls = ["https://github.com/nlohmann/json/archive/v3.11.2.tar.gz"],
sha256 = "0e498fea8a781f7eafc11b9a8efa9b7e28d8fb7e774c0c5a5e30fc4eda309a9e4",
strip_prefix = "json-3.11.2",
build_file = "@com_github_nlohmann_json//:BUILD",
)
Bazel, like other popular C++ build systems, do not include remote build execution (at least for C++). Remote Build Execution (RBE) Is popular option from Google's BuildBuddy RBE. RBE requires a separate server setup and worker machines. An open-source alternative is BuildGrid's buildbox, though it's far more difficult to find information.
Benefits of Target-Level Dependencies:
Bazel and similar tools can cache not only object files but also entire build outputs for specific targets. If a target's dependencies haven't changed, the cached output can be reused, eliminating the need to rebuild the entire target from scratch.
Both distributing compilation units and distributing targets benefit significantly from effective caching mechanisms.
Both distribution strategies benefit from caching by reducing redundant work. This frees up machines to focus on building new or changed parts of the project, leading to more efficient resource utilization. These concept extend to local builds, where you can leverage Bazel's remote caching capabilities. Configure a local cache using --remote_cache to store build artifacts and potentially avoid redundant compilations. Package managers are another implementation of a caching strategy. Stay tunned for more topic.
The best approach is using both strategies. If you need to pick one distributing compilation units can be simpler for smaller projects with well-defined dependencies and few target platforms. Distributing targets tend be more efficient for larger projects with complex build configurations when incremental builds have the most potential.
Here's a decision-making framework to help you choose the right strategy.
This might not translate to all projects types. So for the other side of the spectrum, if you have a monorepo where source files are shared across multiple projects, then distributing the compilation would most likely have the larger impact upfront.
Distributing C++ builds offers a powerful tool to improve development efficiency. By leveraging these strategies and available tools, you can significantly reduce build times and streamline your C++ development workflow. Remember to consider your project's specific needs when choosing the best approach for your build distribution.
You'll know you've done it right when testing is the longest portion of you pipeline.
]]>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.
Traditionally, projects might ship with a single build configuration optimized for production - they are built exclusive for the platforms they support. But what if we built more configurations specifically designed for memory safety checks? We can introduce configurations that enable sanitizers like ASan and LSan during the build process. These configurations would catch memory issues early on, preventing them from reaching production.
This also possible cross-platform, thought it might be more effective to target just one depending on your infrastructure.
As previously covered, CMake Preset are an excellent way to organize build configurations. If you are unsure about them, checkout the old school way or this far more restrictive implementation, there's an elegance to the simplicity presets can bring. Let's take the release preset and wrap that in a pipeline to get started.
Pre-conditions:
Pipeline Stages:
Check the examples for GitHub Actions from the presets post putting these principals practice.
The challenge? Building with multiple sanitizers can significantly impact build times especially if they are already problematic. Here's where the magic of parallel builds comes in. By leveraging tools like CMake, we can define separate build configurations for each sanitizer. More importantly, we can configure these builds to run in parallel, a well established technique to reduce build times.
name: CI with Parallel Sanitizer Builds
on:
push:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest # Make sure to have a proper version-controlled build image
strategy:
matrix:
preset: [release, asan, lsan]
steps:
- uses: actions/checkout@v4
- name: Install dependencies
uses: ./.github/actions/install_deps # Setup caching and call favorite package manager
- name: Configure with preset
run: cmake --preset ${{ matrix.preset }}
- name: Build
run: cmake --build --preset ${{ matrix.preset }}
- name: Run tests
run: cmake --build --target unit_tests_run --preset ${{ matrix.preset }}
- if: matrix.preset == 'release'
name: Upload artifacts
uses: actions/upload-artifacts@v4
with:
paths: build/release
When using sanitizers, it's crucial to ensure that the entire build graph, including third-party dependencies, is built with sanitizers enabled. This guarantees that memory issues are detected across the entire codebase, not just within your own code, as the boundaries are were mistakes are most likely.
As we've established, building with sanitizers can significantly impact build times; to address this challenge, caching mechanisms play a vital role in optimizing the CI workflow. Third-party dependencies are less likely to change, but need to be treated with the same care, between build are offer an effective return on investment for the effort to implement more complex workflows.
Caching third-party dependencies can significantly improve build times by avoiding redundant downloads and builds. This is particularly beneficial when using sanitizers, as the entire build graph needs to be re-evaluated with sanitizers enabled for each configuration.
Here's why caching is crucial:
Several strategies can be employed to effectively cache third-party dependencies when using sanitizers in C++ projects:
Adding onto the pipeline example, this looks like the following:
By adopting this strategy, you can elevate your C++ project's memory safety without sacrificing development speed or introducing workflow friction. Remember, memory safety is not just a CI concern; it's an essential part of the entire development lifecycle. So, build more configurations, leverage parallelization, and empower your developers to write robust, memory-safe code!
]]>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.
A C++ package encapsulates a collection of core artifacts, the lifeblood of your codebase. This does not extend to delivering the product for example as on-premise software but might be bundled for a software development kit. These artifacts serve as building blocks that are ingested by build systems to execute the compilation, archiving, and linking processes. Here's a breakdown of the key components:
#include headers to access the declared entities.There's often a temptation to include Executables (.exe or .out); these can be utilities used during the build process, such as code generators or testing frameworks. However I'd argue there's likely an extension to the idea of a "package" called "tool" which could be specialized and more adapt at covering this use case.
To guarantee robust development, C++ packages must adhere to specific criteria:
The primary goal is to enable downstream consumption; capturing the inputs for the compiler is the practical application of this concept. Packages should be readily consumable by other build systems for downstream projects. A clear and well-defined interface is essential for smooth integration.
While core artifacts form the foundation of a package, however there is more information necessary for compiling and linking which plays a vital role in specifying details like:
C++ packages benefit from avoiding binary compatibility information within the package itself. This simplifies package and leaves the that be tooling specific; often teams have contradictory requirements (save it or break it) and the tooling or vendor specific implementation should not be decided here.
The Build System Should not Care:
Package Managers, Right Tool for the Job:
The Case for "No Compatibility" Definition:
Trade-offs and Best Practices:
However, as a general rule, keeping packages free of binary compatibility information promotes flexibility and maintainability for C++ projects in diverse environments. This approach fosters collaboration between packages, builds systems, and package managers, resulting in more robust and adaptable C++ development ecosystems.
Packages empower C++ developers with a structured and efficient way to organize code, promote reusability, and ensure project maintainability. By adhering to the essential properties outlined in this guide, you can craft robust and portable packages that act as the cornerstones of successful C++ development endeavors.
For further exploration, consider delving into specific build systems like CMake or Make to understand how they handle package creation and configuration. Explore popular package managers like Conan or vcpkg that simplify dependency management and facilitate the sharing of C++ packages across diverse projects.
]]>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.
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.
The code required to activate this CMake feature is verbose and complex. A prime example is the well-known cmake-init project, which includes the install-rules.cmake file. This file clearly demonstrates the significant amount of boilerplate code present.
This complexity arises from the need to cover many use cases. Ideally, most users expect a seamless experience "out of the box" without needing to provide any input. However, a global system install isn't a viable long-term strategy, and advanced users will expect custom installation locations to function correctly. Additionally, package managers like Conan and Vcpkg rely on this same mechanism to capture the output. All these scenarios become even more intricate due to CMake's lengthy list of default search path that can be further extended by providing hints, both at the command line and from the consumer's build scripts.
Testing the installed CMake config files helps prevent such headaches by guaranteeing:
Before we can automate the testing, we need to setup the installation scripts first.
The foremost expert on this subject is likely Craig Scott, author of Professional CMake: A Practical Guide. His book includes two very relevant sections: Chapter 33: Finding Things, which covers using find_package, and Chapter 34: Installing. This refers to the sixteenth edition of the book; later editions include improvements with topics like C++20 Modules.
The minimal example presented, is very similar to this:
include(GNUInstallDirs)
include(CMakePackageConfigHelpers)
configure_package_config_file(
MyProjConfig.cmake.in MyProjConfig.cmake
INSTALL_DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/MyProj
NO_SET_AND_CHECK_MACRO
NO_CHECK_REQUIRED_COMPONENTS_MACRO
)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/MyProjConfig.cmake
DESTINATION ${CMAKE_INSTALL_LIBDIR}/cmake/MyProj
COMPONENT ...
)
Alternatively, check the CMake documentation's example for the same segment of code.
However, this approach does not include exporting namespaced targets or ensuring version compatibility, both of which are highly recommended practices. For a more comprehensive example, we can revisit the cmake-init project. It offers an example repository for a shared library. This sample project provides a more complete view of the generated install rules (which required some trimming for this article).
The installation process typically involves two key files:
install-config.cmake file typically includes another file, ${project}Targets.cmake, which contains the details about the library's public and interface properties. Public properties define aspects of the library visible to users, while interface properties facilitate internal communication between targets within the library.include("${CMAKE_CURRENT_LIST_DIR}/sharedTargets.cmake")
install-config.cmake file dictates how the configuration files are generated and installed. It specifies the destination for the generated files and which library targets should be included in the installation process. While we won't delve into the specifics of this file here, skimming its contents can give you a general understanding of the configuration involved.include(CMakePackageConfigHelpers)
include(GNUInstallDirs)
# find_package(<package>) call for consumers to find this project
set(package shared)
install(
DIRECTORY
include/
"${PROJECT_BINARY_DIR}/export/"
DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}"
COMPONENT shared
)
install(
TARGETS shared_shared
EXPORT sharedTargets
INCLUDES DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}"
)
write_basic_package_version_file(
"${package}ConfigVersion.cmake"
COMPATIBILITY SameMajorVersion
)
# Allow package maintainers to freely override the path for the configs
set(
shared_INSTALL_CMAKEDIR "${CMAKE_INSTALL_LIBDIR}/cmake/${package}"
CACHE STRING "CMake package config location relative to the install prefix"
)
set_property(CACHE shared_INSTALL_CMAKEDIR PROPERTY TYPE PATH)
mark_as_advanced(shared_INSTALL_CMAKEDIR)
install(
FILES cmake/install-config.cmake
DESTINATION "${shared_INSTALL_CMAKEDIR}"
RENAME "${package}Config.cmake"
COMPONENT shared
)
install(
FILES "${PROJECT_BINARY_DIR}/${package}ConfigVersion.cmake"
DESTINATION "${shared_INSTALL_CMAKEDIR}"
COMPONENT shared
)
install(
EXPORT sharedTargets
NAMESPACE shared::
DESTINATION "${shared_INSTALL_CMAKEDIR}"
COMPONENT shared
)
Again this example does not have optional features or dependencies that are required or optionally supported. We'll take a look at a more complex install-config.cmake equivalent.
config.cmake.in FileLet's delve into a real .cmake.in (or install-config.cmake to reference the cmake-init terminology), this comes from Thalhammer/jwt-cpp which will serves as the more complicated example which has support for both optional and interchangeable dependencies.
If you have ideas on how to improve on this formula, don't hesitate to contribute to the project.
It should be very easy to see the jump in complexity from cmake-init's one liner configuration file.
@PACKAGE_INIT@
set(JWT_EXTERNAL_PICOJSON @JWT_EXTERNAL_PICOJSON@)
set(JWT_SSL_LIBRARY @JWT_SSL_LIBRARY@)
include(CMakeFindDependencyMacro)
if(${JWT_SSL_LIBRARY} MATCHES "wolfSSL")
find_dependency(PkgConfig REQUIRED)
pkg_check_modules(wolfssl REQUIRED IMPORTED_TARGET wolfssl)
list(TRANSFORM wolfssl_INCLUDE_DIRS APPEND "/wolfssl") # This is required for OpenSSL compatibility
else()
find_dependency(${JWT_SSL_LIBRARY} REQUIRED)
endif()
if(JWT_EXTERNAL_PICOJSON)
find_dependency(picojson REQUIRED)
endif()
include("${CMAKE_CURRENT_LIST_DIR}/jwt-cpp-targets.cmake")
The behavioral requirement is to preserve the options specified when the consumer configured the project so they do not need to be repeated downstream.
@PACKAGE_INIT@ with a block of code that sets up variables with a PACKAGE_ prefix based on values defined earlier in the script. This ensures relative paths within the installed config file are adjusted based on the installation location.@JWT_EXTERNAL_PICOJSON@, @JWT_SSL_LIBRARY@): These placeholders are replaced with actual values during the install process, allowing for customization based on user configuration. These value will be captured in the generate config.cmake files.JWT_SSL_LIBRARY) and whether an external picojson library is used (JWT_EXTERNAL_PICOJSON).
PkgConfig and additionally modifies the include search path to access the OpenSSL compatibility API.jwt-cpp-targets.cmake) that defines the actual library targets exposed to consumers through find_package. This targets file is generated by CMake on install and include the namespace, include directories, link libraries and other properties set to the install or public interface of the target.There's a lot that might happen when find_package(jwt-cpp CONFIG REQUIRED) is called so let's unpack them:
cmake --preset release && cmake --install build/ where none of the options are modified.CMAKE_INSTALL_PREFIX to a path which is not on the CMake's default search list.cmake . -DJWT_DISABLE_PICOJSON should create an installation where this optional dependency is not included and is carried downstream provided the #define with the jwt-cpp::jwt-cpp target.JWT_SSL_LIBRARY this should be captured in the installation and the correct find_dependency is called without adding extra unnecessary dependencies.With these outlined we'll be able to leverage some Behavioral Driven Development practices and define test cases such as "Should find jwt-cpp with picoJSON" to ensure the functionality for consumers is correct.
Let's write some acceptance tests using GitHub Actions. Here's how it works:
cmake that are desired.
cmake --install with different prefixes (CMAKE_INSTALL_PREFIX) to simulate various installation scenarios.find_package Test: Within a separate build directory for each test, the workflow uses find_package to locate your library and verifies if all required information is found (e.g., target names, include directories).jobs:
default:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [macos-latest, windows-latest, ubuntu-latest]
steps:
- uses: actions/checkout@v4
- uses: lukka/get-cmake@latest
- name: setup
run: |
cmake --preset release
sudo cmake --build --preset release --target install
- name: test
working-directory: tests/cmake # Example consumer project
run: |
cmake .
cmake --build .
By adapting this workflow to use the various options or dependencies in isolation, you can achieve a reliable and future-proof testing strategy. This is extensible by expanding the matrix in a new job to include non-default installation paths or with different present names for pre-defined configurations that are supported.
A robust approach to verify your CMake config file installation is by creating a basic consumer project. This technique has the added benefit of acting as living documentation for potential consumer to reference. This section explores this technique using a sample CMakeLists.txt file.
Sample Consumer Project:
cmake_minimum_required(VERSION 3.8)
project(jwt-cpp-installation-tests)
# Setup your own source code here
set(TEST CACHE STRING "The test source file to be used")
find_package(jwt-cpp 0.7.0 EXACT REQUIRED CONFIG)
add_executable(test-project ${TEST}.cpp)
target_link_libraries(test-project jwt-cpp::jwt-cpp)
Explanation:
Project Setup: Required field to have a standalone CMake project.
cmake_minimum_required(VERSION 3.8): Specifies the minimum required CMake version.project(jwt-cpp-installation-tests): Names the project for better organization.Test File Selection:
set(TEST CACHE STRING): Defines a cache variable named TEST to store the path of the source file to compile. This allows you to easily switch between different test files which should all work with the same entry point. By leveraging compiler features we can test for the presence of preprocessor and header files to ensure the installation is complete.Finding the jwt-cpp Library:
find_package(jwt-cpp 0.7.0 EXACT REQUIRED CONFIG): Attempts to locate the jwt-cpp library using find_package.
0.7.0 EXACT: Specifies the exact version of jwt-cpp to search for. This will help ensure the value is correctly captured by the write_version_file CMake helper.REQUIRED CONFIG: Ensures the CMake will return a non-zero exit code if our library is not found.Building the Test Executable:
add_executable(test-project ${TEST}.cpp): Creates an executable named test-project that is built from the source file specified by the TEST variable.Linking the Library:
target_link_libraries(test-project jwt-cpp::jwt-cpp): Instructs the linker to include the jwt-cpp library when building the test-project executable. This implies all the transitive dependencies will be included implicitly.jwt-cpp library as well as the dependencies and ny optional features.CMAKE_FIND_DEBUG_MODE, introduced in version 3.17, is an excellent tool to check the search paths being used.This approach provides a quick and straightforward method to verify the functionality of your CMake config file installation.
The use case outline earlier have lot of variations, most of which include the users configure of a non-default configuration. Ensuring the generated and installed targets and config.cmake files correctly is also important.
Testing Different Options:
The "No Base64" option allows consumer to exclude the jwt-cpp built-in functions, these generalized implementation are not extensively optimized and many other libraries exist with this feature. This can be described as "Should find jwt-cpp without including base.h" as out BDD test case. This unique configuration will need it's own job. This will perform an out-os-source build and install with the option set to ON before an in-source consumer workflow to configure and build.
no-base64:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: lukka/get-cmake@latest
- name: setup
run: |
mkdir build
cd build
cmake .. -DJWT_DISABLE_BASE64=ON -DJWT_BUILD_EXAMPLES=OFF
sudo make install
- name: test
run: |
cd tests/cmake
cmake . -DCMAKE_PREFIX_PATH=/usr/local/cmake -DTEST:STRING="base64-is-disabled"
cmake --build .
In order to test the library is installed and packaged correct, we can define our source test .cpp file instrumented with #error directives and _has_include marco to validate the contents.
#ifndef JWT_DISABLE_BASE64
#error "This test expects 'JWT_DISABLE_BASE64' to be defined!"
#endif
#if __has_include("jwt-cpp/base.h")
#error "This test expects 'jwt-cpp/base.h' to be absent from the installation!"
#endif
#include "jwt-cpp/jwt.h"
int main() {
jwt::date date;
return 0;
}
Testing Different Dependencies:
By strictly controlling our build environment and pinning the dependency's version we'd like to test, we can ensure a robust test case for "Should find jwt-cpp and use wolfSSL" can be implemented.
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: lukka/get-cmake@latest
- uses: ./.github/actions/install/wolfssl
with:
version: ab3bbf11e9d39b52e24bf42bbc6babc16d4a669b
- name: setup
run: |
mkdir build
cd build
cmake .. -DJWT_SSL_LIBRARY:STRING="wolfSSL" -DJWT_BUILD_EXAMPLES=OFF
sudo make install
- name: test
run: |
cd tests/cmake
cmake . -DTEST:STRING="wolfssl-is-used"
cmake --build .
Once again, we can design a test source file to validate the include and marco from the dependency are provided. This also includes calling a core function from the library, wolfSSL_library_init() in this case, to ensure the library or runtime as well as link paths are correctly setup for consumers.
#if !__has_include(<wolfssl/ssl.h>)
#error "missing wolfSSL's SSL header!"
#endif
#ifndef OPENSSL_EXTRA
#error "missing wolfSSL's OPENSSL_EXTRA macro!"
#endif
#ifndef OPENSSL_ALL
#error "missing wolfSSL's OPENSSL_ALL macro!"
#endif
#include "jwt-cpp/jwt.h"
#include <wolfssl/ssl.h>
int main() {
wolfSSL_library_init();
jwt::date date;
return 0;
}
This currently does not exists! With the big package managers running curated central repositories, their repositories and internal CI systems need to be aware of your project. The burden rests on their respective communities integrated and contributing back.
This automated testing approach empowers you to deliver a robust and user-friendly library by ensuring your CMake config files function as intended across various environments. Test Essentials! Run standard install commands (cmake --preset release && cmake --install build/) to verify config file placement. Building on this to handle more complex requirements like optional features or dependencies, remember the following approach:
cmake --presets to configure different supported settings and configurations.cmake --install with varying prefixes to mimic real-world user scenarios.find_package Verification: Confirm your library and crucial information are found using find_package in separate detected sample consumer project and utilize a pass/fail test strategy.If you are looking to implement and practice these ideas, this is an excellent opportunity to get involved in open-source libraries you are using, may projects will appreciate a thorough test suite for these features.
]]>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!
There are positive signs! Build times, a crucial metric for build pipeline efficiency, are improving. The distribution of pain levels is also shifting downward. "Major Pain" responses have decreased to 43%, while "Minor Pain" holds steady at 37%. "Not Significant" responses are on the rise, reaching nearly 20%.
For enhanced clarity, I've opted to present the rest of the data in a table format in addition to the graphs. While the official diagram plugin, Mermaid-JS, doesn't currently support legends for this specific chart type (see issue mermaid#5292); the tables allow for a clear connection between the data points and their corresponding lines.
Here's a summary of the 2024 Annual C++ Developer Survey "Lite":
While the survey results provide valuable insights, access to the raw data would allow for a more granular analysis. This would enable us to answer intriguing questions like:
With additional data, we could delve deeper into the trends and potentially uncover hidden correlations.
It appears there may be a discrepancy in the choices for this question. Since CI/CD encompasses building, testing, and deploying code, the combined total of these individual options should ideally exceed the percentage of respondents who use CI/CD. For future surveys, ensuring clear and comprehensive answer choices would improve the interpretability of the results.
Given the amount of focus on memory safety, as the 5 dedicated "pain" questions to it would suggest, and how these techniques improve security. It might be a surprise to learn these number have not see any significant movement. It seems to suggest the burden of upgrading CI/CD pipelines might be inhibiting the progress in adopting these tools.
As the article C++20 modules and Boost: an analysis highlights, concerns exist around managing the potential increase in complexity for build systems. This is likely in addition to modules introducing interoperability challenges between build systems and package managers - a concern that many of respondents are likely to have as usage of multiple build systems was very high - might delay the adoption process until broader tooling support matures.
The survey results reveal a fascinating interplay between C++ and other programming languages. Python's dominance (73%) as a companion language likely stems from its versatility in scripting, data analysis, and build orchestration tasks, particularly for developers supporting multiple platforms (a common scenario based on the survey). Where JavaScript (27%) and C# (24%) likely play a significant role due to their platform specific integrations which resonates well with the high usage of Windows (over 60%). Meanwhile, the rise of Rust (18%) aligns with the growing emphasis on memory safety in C++ development.
How do you manage your C++ 1st and 3rd party libraries?
| Year | 1. Inlined | 2. Dedicated | 3. System Manager | 4. Download | 5. Conan | 6. vcpkg | 7. other | 8. nuget | 9. None |
|---|---|---|---|---|---|---|---|---|---|
| 2021 | 68.96% 1,284 | 55.75% 1,038 | 37.49% 698 | 32.28% 601 | 15.95% 297 | 14.82% 276 | 9.02% 168 | 7.84% 146 | 1.66% 31 |
| 2022 | 69.91% 827 | 50.89% 602 | 38.80% 459 | 27.56% 326 | 18.93% 224 | 18.34% 217 | 9.30% 110 | 8.37% 99 | 1.35% 16 |
| 2023 | 68.11% 1,162 | 48.30% 824 | 36.23% 618 | 27.43% 468 | 21.34% 364 | 18.93% 323 | 11.25% 192 | 7.50% 128 | 1.41% 24 |
| 2024 | 68.54% 854 | 48.48% 604 | 37.80% 471 | 25.60% 319 | 19.34% 241 | 19.10% 238 | 14.53% 181 | 5.30% 66 | 1.69% 21 |
Taking the sum of usage of Conan, Vcpkg, Other, and Nugest (disclaimer: "other" is assumed to be another package manager but there's no data about what people wrote) and calculating the delta over the previous year.
Calculating the Pearson's Product Moment Correlation Coefficient. Give r = -0.9983817302 where "−0.8 > r > −1" is Strong negative linear correlation. Nearly perfect.
This is the best evidence for the entry point to using a package manager is handling dependencies with their own unique workflow and pipelines. Eliminating those extra processes can certainly reduce the pain of managing build system complexity.
| Year | Dedicated | Package Managers |
|---|---|---|
| 2022 | -4.86% | 7.31% |
| 2023 | -2.59% | 4.08% |
| 2024 | 0.18% | -0.75% |
Comparing other categories against Package Managers and System Package Managers did not result in any significant correlations which exception to slight connection with downloads getting replace by package managers.
It is encouraging to see Nuget, which is for .NET and C# losing ground. The data for "other" will hopefully inspire a revised list of choices next year. This would make up and coming package managers more appealing by helping to promote and attract users. This would be an excellent driver for more innovation in this space.
There's is thankfully a large focus on improving the tooling and "evolving the ecosystem", to steal the lingo, so let's dive in.
The colors are Major Pain, Minor Pain, Not Significant Pain for the follow graphs.
Positive signs for supporting external dependencies! The percentage of developers reporting this topic as a major pain point has steadily decreased, with a 3% decline from 2021 to 2024. This is accompanied by a corresponding increase in those reporting it as a minor pain or not significant at all.
| Year | Major Pain | Minor Pain | Not Significant |
|---|---|---|---|
| 2021 | 48.46% 899 | 35.47% 658 | 16.06% 298 |
| 2022 | 47.63% 563 | 34.77% 411 | 17.60% 208 |
| 2023 | 47.37% 810 | 35.09% 600 | 17.54% 300 |
| 2024 | 45.43% 571 | 36.44% 458 | 18.14% 228 |
With the previous year
| Year | Major Pain | Minor Pain | Not Significant |
|---|---|---|---|
| 2022 | -0.83% | -0.70% | 1.54% |
| 2023 | -0.26% | 0.32% | -0.06% |
| 2024 | -1.94% | 1.35% | 0.60% |
Encouraging signs for build times! So much so, it's included twice. Over the past four years, the survey data reveals a consistent downward trend in the percentage of developers reporting long build times as a major pain point. This decrease of 2.38% from 2021 to 2024 suggests that the C++ build ecosystem is becoming more efficient. There's a still a very slim number of developer who are not burdened by long times times.
Further exploration could investigate:
| Year | Major Pain | Minor Pain | Not Significant |
|---|---|---|---|
| 2021 | 45.24% 837 | 38.05% 704 | 16.70% 309 |
| 2022 | 43.94% 515 | 38.65% 453 | 17.41% 204 |
| 2023 | 43.34% 735 | 37.56% 637 | 19.10% 324 |
| 2024 | 42.86% 537 | 37.35% 468 | 19.79% 248 |
The survey results indicate a persistent challenge. While there's a slight decrease in the percentage of developers reporting it as a major pain point (down to 1% from 2023 to 2024), it remains a significant hurdle for many (nearly a third of respondents!). There's little to no improvement over the 2021 data.
Is there a light at the end of the tunnel?
Perhaps! The data does shows a downward trend in those reporting it as a minor pain, suggesting some improvement. Additionally, the "Not Significant" category remains relatively stable. This could indicate that for certain segment of the ecosystem, setting up CI pipelines is becoming a more manageable task.
| Year | Major Pain | Minor Pain | Not Significant |
|---|---|---|---|
| 2021 | 30.85% 568 | 42.15% 776 | 27.00% 497 |
| 2022 | 33.73% 394 | 40.75% 476 | 25.51% 298 |
| 2023 | 31.35% 531 | 40.85% 692 | 27.80% 471 |
| 2024 | 30.35% 376 | 42.53% 527 | 27.12% 336 |
The data on setting up development environments reveals a fascinating trend. While there's a positive shift with more respondents finding it a "not significant" pain point (up to 31.93% in 2024), there's also a concerning slight increase in those reporting it as a major pain (26.27% in 2024).
One explanation could be advancements in techniques for build script. There are some very high quality sources for CMake. That category saw a in the number of respondents experiencing pain that. However, the challenge of setting up the entire environment, especially for complex systems, seems to be persisting.
| Year | Major Pain | Minor Pain | Not Significant |
|---|---|---|---|
| 2021 | 25.82% 479 | 43.56% 808 | 30.62% 568 |
| 2022 | 27.83% 329 | 42.98% 508 | 29.19% 345 |
| 2023 | 26.83% 459 | 41.09% 703 | 32.09% 549 |
| 2024 | 26.27% 330 | 41.80% 525 | 31.93% 401 |
Get subscribed or make sure to follow. I will absolutely be continuing to post about these topics. There is 15-25% range of developers that have figured out how to build, test and ship this code with a not significant amount fo pain, and the goal is to get you there as well.
There an interesting pessimism that was present in 2022, maybe a global health pandemic and financial uncertainty impacted how respondents felt? It does make the current data trend well.
]]>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.
This is important because you probably have a different one. Most teams actually have a very weak or loose definition for both of these terms.
A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.
It's reproducible if anyone else can verify it. That's a pretty tall order, but seems like the rebuild it a few times is the low hanging fruit. Most teams are not reaching this level of reproducibility, regardless it's the standard.
A package management system is a collection of software tools that automates the process of installing, upgrading, configuring, and removing [...] distributions of software and data in archive files. Designed to eliminate the need for manual installs and updates to ensure the authenticity and integrity of the package. Putting packages in the correct locations in your project and writing the code to include the package(s) in your project. [ref]
The definition for a "package manager" has evolved, the expectation for what it should do and provide has grown as SDLC has matured as a topic. A package manager must provision a unique isolated environment (i.e. automatically pull in only necessary the dependencies). This is the best practice across ecosystems take Python and it's virtual environments which are now the recommendation.
The key to a successful workflow lies in understanding the strengths of each approach and using them together. Here's how:
Package managers like Nuget, Conan, and Conda offer a compelling advantage: pre-built libraries. These tools save developers countless hours by eliminating the need to local build dependencies from source. A notable way this is achieved is by large well tested repositories which often provide abstractions to the project specific inputs that often existing. This translates to faster development cycles and a more streamlined workflow. However, package management can introduce challenges.
The importance of these packages is they are re-usable, typically any changes to the output contents will be labeled, this makes the need of tracking individual variations of source code take less precedency. The output or package of one project is often the input for another. This is a powerful abstraction when aiming for reproducible builds as it can simplify the integration of third-party dependencies which likely do not conform the commandments.
Reproducible builds prioritize control and consistency. By building everything from source with a defined set of tools, developers ensure that the build process is deterministic. This means that the same source code will always produce the same binary, given the same environment. Faster more trust worthy builds and test results ensure developers are focused and boost productivity [ref].
The downside of reproducible builds is the complexity they can introduce. Manually managing dependencies and build systems can be time-consuming and error-prone. Often teams can not rely on the standard build tools, for examples, Rust's compiler, rustc, has support for this but that has not been added to Cargo [ref] the main build system for that ecosystem. This ends up becoming a burden with trying to make the build reproducible when incorporating third-party dependencies. If external build systems are not directly supported by the reproducible build system then you are likely to lose control of the inputs and settings. The lack of insight to the source build graph also reduce the effectiveness of the build tree shaking and caching strategies less efficient. To close out the pain point the outputs of dependencies can be project specific and require extensive manual work to be integrated back into the reproducible system.
In order to ensure easy of use, build systems overwhelming will allow you to pull in system libraries. This loose rule makes it very easy to break the hermetic build ideal required to be reproducible; resulting with a non-reproducible environment. This problems are beautifully outlined in a talk by Andreas Herrmann titled Fast, correct, reproducible builds with Nix + Bazel. The challenge of doing this is also outline in Buck2 so it's quiet general.
Using a build system that offers distributions and correct dependency set and incremental builds while a package managers strictness with toolchain management and control over third-party dependencies is the winning combination. Additionally package managers which offer distribution of compiled artifacts rather then local caching can correctly reduce the number for build branches. To round off the shopping list, not only should the package manager provide an isolated environment, the build system should also enforce this by isolating the build tree's filesystem (i.e not have default search paths).
Utilize Package Managers for Controlling Toolchains: The number one advantage of using a package manager is the large community driven repositories which have generally been tested against a large list of toolchains. The build instructions are typically well controlled already as these tool setup for handling the variations in the build scripts. They can handle all the complex mapping of different inputs to each individual flavor of build scripts. This generally makes the integration more streamlined.
Build Critical Third-Party Dependencies: When dealing with critical project dependencies or those with specific version requirements, consider building them from source. This gives you greater control over the build process and ensures compatibility. Being able to resolve more complex graphs to get the best version when managing dependencies is critical. As they all support building from source you will be able to ensure all the impacted make targets are tracked.
Handling Heterogenous Developer Environments: It's very likely on larger distributed teams, individual will have different variations are be slightly skewed in terms of the operating system they use and the supported environments. This requires a high-order tool that is able to understand the current system configuration and provide the correct binaries. Using a package manager to control and provision the exact build environment and dependencies will reduce this by creating the dedicated sandbox required.
When exploring integration possibilities between package managers and reproducibility focused build systems in the realm of C++ development, Conan stands out as a supportive tool. Conan not only supports Bazel, but also offers advanced features such as build graphs and toolchain combinations, so you can very likely achieve this with other build systems as well. However, it's worth noting that Conan does support for build tools, it lacks direct integration with Bazel's user-defined toolchains through it's compiler_executables configuration, a feature that is support with it's CMake Presets.
On the other hand, Vcpkg, another prominent package manager, is primarily tailored for CMake, limiting its compatibility with other build systems. This has led some developers to resort to manual configurations, effectively hardcoding dependencies into Bazel build files for each package. Despite efforts to bridge this gap, Bazel still faces challenges in accommodating various C++ package managers, with Nix and Conan emerging as the preferred choices due to their existing support. The limited interoperability between other build systems exists if you are curious.
Switching gears, within the embedded space, Yocto presents a compelling case with its BitBake package manager. Yocto's support for reproducible builds has contributed to its success, offering a reliable solution for managing dependencies and ensuring consistent build outputs. Unfortunately this is not seen in other application specific segments of the ecosystem.
The integration of package management and reproducible builds in C++ development presents a nuanced landscape where both approaches, although initially seem contradictory, can harmonize to enhance development workflows. Package managers like Nix or Conan offer the advantage of tightly controlled libraries and environments, reducing development cycles needed to create robust hermetic build environments. Complementary to this, reproducible builds prioritize control and consistency by rebuilding everything, ensuring deterministic outputs and boosting productivity through more efficient optimization that can be made with these constraints.
Despite the challenges each approach presents, the key lies in understanding their respective strengths and leveraging them together effectively. Utilizing package managers for controlling toolchains and handling critical third-party dependencies can enhance build processes, while reproducible builds offer deeper control and insight into build outputs.
Key Takeaways:
Together they guarantee identical binaries from identical source code and environments, aiding ensure correct secure software.
]]>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.
Here's the magic:
const acts as a safeguard against accidental changes, preventing bugs caused by unintended assignments.const to improve performance by making assumptions about the data's immutability.Let's implement a hypothetical C++ CI service.
#include <string_view>
class build_image {
public:
build_image(std::string_view version, std::string_view name) : version_(version), name_(name) {
download_build_image(*this); // Takes a non-const to populate in `this->id`
open_shell_handle(*this);
}
std::string version() const { return std::string(version_); }
std::string name() const { return std::string(name_); }
std::string id() const { return id_; }
void id(std::string_view id) { id_ = std::string(id); }
private:
const std::string_view version_;
const std::string_view name_;
std::string id_;
void download_build_image(build_image& image);
void open_shell_handle(const build_image& image);
};
// Contents of a build_image can not be modified while commands are executed
bool run_command(const build_image& image, const std::string& cmd) {
// Simulate opening a shell and executing commands
return true; // Code never fails to compile
}
int main() {
const std::string_view version = "24.04"sv;
const std::string_view name = "ubuntu"sv;
const build_image ubuntu24(version, name);
const auto build_result =
run_command(ubuntu24, "./terrible-do-everything.sh debug all")
std::cout << "Build complete! " << build_result << std::endl;
return 0;
}
Ephemeral, meaning "short-lived," refers to a build environment that is created, used for a specific task (like building software), and then discarded. This approach is gaining traction due to its numerous benefits:
Infrastructure as Code (IaC) refers to the practice of managing infrastructure (like servers, networks, and storage) in a programmatic way using code. Tools like Terraform allow developers to define the configuration of their build environment in code files. These code files can then be version controlled alongside the application code, ensuring consistency and reproducibility.
Version control systems (VCS) like Git play a crucial role in both const correctness and ephemeral builds. It allows you to manage changes to your codebase (enforcing const usage) and the definitions of your ephemeral build environments, fostering a unified Software Development Lifecycle (SDLC) for both.
const correctness through code reviews and linting tools further strengthens the codebase's integrity.A Single Source of Truth: By leveraging version control, you establish a single source of truth for both your code and build environment definitions. This streamlines your SDLC by ensuring everyone works with the latest and approved versions of both components.
Combining const correctness with ephemeral builds and managing them through version control creates a robust and cohesive foundation for reliable software development. You enforce code immutability, guarantee clean build environments for each build, and establish a clear audit trail for changes, leading to fewer bugs, easier maintenance, and ultimately, more dependable software.
Const correctness and ephemeral builds, seemingly separate concepts, share a surprising connection: building a strong foundation for reliable software. Const correctness enforces immutability in your C++ code, while ephemeral builds provide a clean slate for each build. Together, they create a powerful synergy:
Imagine a scenario where a non-const variable in your C++ code accidentally gets modified during the build process. This could lead to unexpected behavior in the final product. Ephemeral builds mitigate this risk by ensuring a fresh, unmodified codebase for each build.
Similarly, consider an ephemeral build environment containing cached data or temporary files from previous builds. This can lead to inconsistencies if these remnants influence the build outcome. Const correctness in your code helps prevent such issues by ensuring the code itself remains immutable, regardless of the build environment.
In conclusion, combining const correctness with ephemeral builds and managing them through version control creates a robust and cohesive foundation for reliable software development. You enforce code immutability, guarantee clean build environments for each build, and establish a clear audit trail for changes, leading to fewer bugs, easier maintenance, and ultimately, more dependable software.
]]>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.
This leads to the Call to Actions. What do you think is a "package"? Headers, Libs, DLLs are pretty obvious. What about Compiler flags? What does Multi-Config mean to you? Is a package valid if it produces ODR violations or does leads to ill-formed programs? Share you ideas and thoughts.
C++ developers are no strangers to dependency woes. Different build systems have their own cryptic ways of handling external libraries, leading to compatibility nightmares and endless versioning headaches. These inconsistencies often culminate in cryptic build errors, leaving developers frustrated and wasting valuable time.
What ever we do it needs to be unanimous for all of us which is a tall order. The best approach is going to be an extensible format but we need to get the core right. So let's focus on those fields.
CPS proposes a standardized format for describing C++ libraries, including:
A minimal CPS focused on core information:
{
"Cps-Version": "0.9",
"Name": "sample",
"Description": "Sample CPS for a static library",
"License": "BSD",
"Version": "1.2.0",
"Default-Components": [ "sample" ],
"Components": {
"sample": {
"Type": "archive",
"Requires": [ "libfoo:core" ],
"Compile-Features": "c++17",
"Definitions": [ "SAMPLE" ],
"Includes": [ "@prefix@/include" ],
"Location": "@prefix@/lib/libsample.a"
}
}
}
You can checkout the CPS' example for a more complete interpretation.
Widespread adoption by C++ build systems and package managers could offer advantages:
The existence of many build systems (or these) and package managers for C++ reflects the diversity of project requirements. The challenge for CPS lies in defining a core set of functionalities that caters to the widest range of projects while remaining flexible enough to accommodate those with specific needs.
The inclusion of overly specific fields like JVM vendors and GLIBC runtime versions raises concerns:
The focus should be on fields all C++ developers use. These specific fields can be saved in a technical recommendation for future work. The specification should allow adding them later.
A common issue with third-party dependencies is including more parts than necessary. A common example is providing a header-only variant and a compiled library in the same installation. This is the example for "Default-Components" in the CppCon 2023 talk. Providing multiple copies of symbols such static and shared result in linker errors and will be error-prone.
Ideally, users shouldn't need to micromanage individual components within a dependency. Including all components by default ensures a well-formed and functional package must be provided by the project. This eliminates the need to specify every piece and reduces the chance of missing something crucial.
The specification does need to allow for granular control over components. An optional "Excluded-Components" field could be introduced, allowing authors to specify parts that are not need during the build process (e.g., executables or experimental additions). This approach balances providing all necessary components for most users while offering flexibility for advanced users to optimize dependency usage.
Current CPS doesn't handle feature-driven projects well. Build options can change a component's functionality and binary compatibility without altering its name, include directories or complier flags. This makes it difficult to specify exactly which features you need when using a dependency.
There are some fields that require a bit more complexity, compiler flags and linker flags are unfortunately platform specific. Currently there is no complete example for having different compiler flags for the the various implementation, however nowarn does give a hit to this problem.
{
// ...
"Platform": {
"Kernel": "linux",
"Compiler": "gcc",
"Compiler-Flags": ["-finline-functions-called-once"] // An unreasonable flag to force on downstream consumers?
},
// ...
}
This is a very open topic, perhaps the CPS is only one configuration since the binary library would not be portable? However the current proposal's example is for an x86_64-Linux which could be used by either Clang or GCC and might (incorrectly) have incompatible flags. The header-only case, where the package and CPS should be re-usable cross operating-systems does not allow describing both MSVC /bigobj and GCC -mbig-obj might be cause to have different CPS with one package.
For CPS to succeed within the C++ ecosystem, it needs to strike a delicate balance:
CPS holds immense potential to streamline C++ dependency management, but questions remain regarding its specific details. If the community can ensure the right level of flexibility and focus on core functionalities, with enough feedback and input, CPS has the potential to be a valuable tool. However, only time and developer adoption will tell if CPS becomes the universal language for C++ dependencies, or remains an ambitious proposal with unanswered questions.
By following these industry-proven best practices, you can establish a robust and sustainable approach to dependency management in your C++ projects:
Effective dependency management is an ongoing journey, but by embracing the insights and strategies outlined in this comprehensive guide, you can conquer the C++ dependency landscape with confidence. Build resilient and maintainable projects, streamline your development process, and empower yourself to deliver exceptional C++ applications.
]]>Imagine building a spacecraft. While the engine is undeniably crucial, neglecting the guidance system, navigation tools, and communication equipment would be disastrous. Similarly, focusing solely on libraries paints an incomplete picture. Every software tool you utilize, from the ground up, contributes to the final product's functionality, stability, and maintainability.
This guide delves into the intricate tooling and dependencies, exploring the various categories, offering effective management strategies, and practical examples across diverse project types. By venturing beyond the surface level of libraries, we equip you with the knowledge and tools to navigate the dependency landscape with confidence and efficiency, ensuring your C++ projects reach their full potential.
Dependencies fall into three broad categories:
If you have a keen eye you'll notice, arguably the most important tool, compilers comes up twice. Differentiate between system tools and build tools by asking, "Does this tool read the source code?" If the answer is no, it's likely a system tool. Conversely, an affirmative response suggests a build tool.
Regardless of the type of dependency (system tool, build tool, or library), adhering to these best practices can ensure a smooth and efficient development process:
1. Version Control:
2. Minimize Dependencies:
3. Regular Updates:
4. Documentation and Testing:
5. Integrate Artifact Management:
Going back to our minimizing dependencies, identifying which layers are more tightly coupled and can use the same tool and process is important. The goal should be enable agility, layers which are updated at drastically different frequents that are not cohesive should be separated.
To illustrate these concepts, let's explore how dependency management can be segmented across hypothetical projects:
Think desktop applications or audio add-in card SDKs. These are often closely tied to the operating system, so compilers and toolchains are managed as system tools. Upgrading the compiler might require compiling it for older operating systems. Build environments are provisioned to reflect the product's lifecycle. Libraries, decoupled from this layer, are tied to the source code with exact versions for consistency. Strong caching solutions can effectively eliminate overhead from frequent library updates.
Consider microservices handling concurrent client connections with high read workloads. System tools depend on the developer's hardware, offering more flexibility for local development IDEs and compilers. These system tools might be managed ad hoc, with team specific instructions. However, container runtime versions have stricter requirements, often using exact runtime images to reproduce production environments. Toolchains can be managed as build tools for more flexibility. Providing build images that extend the runtime ones with the necessary build tools and libraries can serve as an effective caching strategy.
Imagine an extraterrestrial exploration unit comprising heterogeneous hardware architectures, from bare metal to micro-controllers and real-time operating systems, often sharing large communication dependencies. Dedicated cross-compilers and build toolchains are needed for various target platforms, and multiple binary library instances must be organized. These are often tightly coupled and managed together. This will manifest as dedicated build systems with coupled tooling and a separate platform agnostic library management.
Effective dependency management is an ongoing practice, requiring constant evaluation and adaptation. By following these best practices, you can establish a robust and sustainable approach to dependency and artifact management, fostering a more streamlined development workflow, ensuring long-term reproducibility, and simplifying collaboration across teams. Remember, the key lies in striking a balance between leveraging existing functionalities and maintaining control over your project's footprint and complexity.
]]>Right now, it feels that C++ developers have to deal with way more than just writing business logic code. [...] Allowing devs to focus more on coding rather than trying to solve problems of the ecosystem would probably be liberating
Xymitoulias suggestion that allowing developers to focus more on coding, rather than grappling with ecosystem problems, would be liberating. He's not alone, Bill Hoffman, CTO behind CMake supports this ideal of simplifying the developer workflows, something we've seen put in place with recent improvements to the popular build system.
While building in C++ certainly comes with its challenges, streamlining this process is our collective goal. So, let's delve into the core focus as it relates to C++ and dispel some common misconceptions.
These ideas have been circulating for quite some time.
All aspects of software production Software engineering is not just concerned with the technical processes of software development but also with activities such as software project management and with the development of tools, methods and theories to support software production. "1.1.2 What is software engineering?" - Software Engineering (8th ed.) ISBN 978-0-321-31379-9
This quote, from a book originally published in 1982, highlights the broader scope of software engineering, encompassing not only technical development but also project management and the development of tools and theories supporting software production.
Yet, expecting individuals to be experts in every tool, method, and theory is unrealistic. The diversity of modern software tooling and platforms necessitates specialized team members with technical skills and a passion for these tools. A Software Engineering team should consist of various roles catering to different aspects of the development process.
Diego Rodriguez-Losada, the lead architect and co-found of Conan, one of the leading C++ package managers, presented the idea DevOps is dependency and package management over time in his 2022 CppCon presentation. I would open that up to include not just the toolchains and libraries you use but the infrastructure which supports the builds. This quote, succinctly captures the question and motivation for doing this.
We propose that "software engineering" encompasses not just the act of writing code, but all of the tools and processes an organization uses to build and maintain that code over time. What practices can a software organization introduce that will best keep its code valuable over the long term? How can engineers make a codebase more sustainable and the software engineering discipline itself more rigorous? "Programming Over Time." Software Engineering at Google (2020). ISBN 978-1-492-08279-8
As a DevOps Engineer, the aim is to support Software Engineering activities past, present and future, which for C++ include:
This amalgamation constitutes the Software Development Lifecycle (SDLC), with security being a top priority though out. Strong collaboration among team members with diverse skills ensures that developers can focus on implementing product features, while DevOps practices uphold the integrity and reliability of the software.
This section is a small rant. @me on social media for discussion!
While criticism of a "fragile hodgepodge system of jerry-rigged things that were never intended to work together" resonates with many in the C++ community, I'd argue that is a bias based on the fragmentation within the ecosystem. It's essential to broaden our perspectives before drawing conclusions.
In many ecosystems, building projects is trivial, with straightforward commands like cargo build, npm build, or maven build. This is why we only hear about CI/CD with no "continuous building" concept which is completely skipped over. Once the challenge of building applications at scale for numerous developers multiple times a day is overcome, it becomes less of a focal point at conferences. This is why cmake --build --preset release is a huge step in the right direction.
So maybe it is understandable to see the remark "DevOps has such a full stack vibe about it"? Not really, fullstack means something completely different. DevOps is a bridging the gap between IT Operations and Software Development. Contrary to beliefs that C++ is excluded from this paradigm, various tools and platforms support C++ development within the DevOps framework. GitHub Actions and Azure DevOps platoformns have support for less common toolchains like MSYS2/Mingw-64. GitLab and Gitea have integrations for Conan packages. Jenkins has been used for C++ CI/CD for many years and helped pioneer concepts like Pipelines as Code.
Comments like "neverending fighting non-coding related bugs is fun but only from devops perspectives" miss the mark. A strong DevOps Engineer possesses knowledge of Infrastructure as Code, enabling them to develop well-designed applications compatible with distributed systems and third-party services. Learning HCL for Terraform, extending it with Golang, and developing test are absolutely fundamental just like any robust software stack. It's no different then developing on top of Boost.Asio.
To put it all into perspective, as a C++ developer, grappling with tedious build processes and platform-dependent multithreading complexities is a familiar struggle. However, embracing DevOps principles can alleviate these challenges, allowing developers to focus on crafting robust and efficient code.
In Xymitoulias post, Hoffman wrote:
It is all about creating an environment where C++ developers can focus on code and have the DevOps happen for them.
And I think that's the perfect place to aim for.
]]>Join in and delve into the strengths and weaknesses of these diverse solutions, empowering you to make informed choices and conquer the challenge of dependency management in your C++ endeavors.
To help you navigate this diverse landscape, let's explore a consolidated overview of popular tools used as C++ package managers, highlighting their strengths and weaknesses along the way. This list is in relevance order, based on factors like how well it works as a package manager and how prominent is it in the ecosystem.
This list provides a snapshot of the evolving C++ package management landscape, but the journey doesn't end here! More feedback is needed. Have you tried any of these solutions? Are there hidden gems missing? Feel like the order is wrong? Share your experiences and recommendations in the comments on social media.
Vcpkg is a cross-platform package manager for C and C++ libraries, simplifying dependency acquisition and management on Windows, Linux, and macOS. Developed by Microsoft, it offers a comprehensive catalog of libraries which can be built locally, seamless integration with popular development environments, and straightforward command-line usage.
Tutorial Video: link
Conan is a powerful and flexible C and C++ package manager designed to simplify dependency management across different platforms and build systems. With Conan, developers can easily declare, install, and manage dependencies for their projects, ensuring seamless integration of third-party libraries without the hassle of manual configuration. Offering support for both public and private package repositories, Conan facilitates efficient dependency resolution, versioning, and package reuse, empowering developers to streamline their C and C++ development workflows with ease.
Tutorial Video: link
Xmake/Xrepo, is a modern and cross-platform build system designed for efficiently compiling and managing C, C++, and other programming language projects. With a focus on simplicity, flexibility, and speed, xmake simplifies the build process by providing an intuitive Lua-based configuration file that allows developers to describe their project's build requirements and dependencies concisely.
Spack is a package manager for scientific computing and HPC environments, enabling software installation and management across various architectures and compilers, enabling reproducibility and efficient collaboration in research and computational workflows.
Hunter is a CMake-driven package manager for C and C++ projects, providing a simplified way to manage dependencies and integrate them into the build process, facilitating efficient development and collaboration in C++ projects.
CPM (CMake Package Manager) is a lightweight package manager integrated withing your project's CMakeLists.txt, enabling simplified dependency management and seamless integration of external libraries into C++ projects.
These tools are doing double duty.
Meson is a fast and user-friendly build system designed for efficiently compiling and managing C, C++, and other programming language projects, offering simplicity, speed, and cross-platform support for streamlined development workflows.
Bazel can be a powerful and scalable build system developed by Google, supporting multiple programming languages including C++ and providing correctness, reproducibility, and speed for large-scale software projects.
The Nix package manager is a powerful and purely functional package manager used in NixOS and other Linux distributions. It enables users to manage software packages and configurations in a reproducible and isolated manner, facilitating atomic upgrades and rollbacks.
Build2 is a modern and efficient build system designed for C and C++ projects, offering simplicity, scalability, and reliability for managing dependencies and building software.
SCons is a software construction tool written in Python, providing a flexible and customizable build system for C and C++ projects, emphasizing simplicity and ease of use for managing project builds effectively.
Tipi.build is a versatile and customizable build system for C++ projects, designed with simplicity and flexibility in mind, offering efficient cloud based workflows.
Tutorial Video: link
SoupBuild is a distributed build system with an almost no compatibility definition. This is similar to Bazel land Vcpkg respectively - both combined into a cargo inspired build tool chain.
Gradle is a build automation tool known for its flexibility and scalability, primarily used for Java projects but also supporting other languages like C++ through plugins. It handles dependency management, compilation, testing, and packaging of software.
Conda is a versatile package manager and environment management system primarily used for Python, but it also supports other languages like C++ and R. It simplifies dependency management and enables easy creation, sharing, and reproduction of software environments across different platforms.
The Yocto project's BitBake is a complete embedded Linux system creation environment. BitBake is the build tool used within Yocto to manage the entire build process, including compiling source code, packaging software, and creating a final operating system image for your target device.
This is a bonus shout out. You should not be considering these but they deserve credit.
Buckaroo is a package manager designed for C++ developers using the Buck build system, streamlining dependency management and integration into projects for efficient development workflows.
CGet is a package manager designed to work with CMake and non-CMake packages. It provides a flexible way to install packages from a directory, file URL, or Github repository.
requirements.txt.Teaport is a dependency manager designed specifically for C++ projects, inspired by the simplicity and flexibility of CocoaPods. It prioritizes leveraging existing tools and focuses on providing a separation between dependency management and build systems.
project.teaspec.lock) to guarantee reproducible builds by locking down exact dependency versions.scp, ssh, and rsync for downloading dependencies. Difficult to scale compared to HTTP with a load balancer or CDN.The best C++ package manager for you will depend on your specific needs and preferences. Consider factors such as:
Ultimately, the best way to choose a C++ package manager is to try out a few different options and see which one you like best.
First things first: Let's dispel a common misconception. System package managers like rpm and apt are great for keeping your operating system humming, but they're not designed for the unique challenges of C++ development. That's where C++ specific package managers like vcpkg, Conan, and Xrepo come in.
These specialized tools understand the pain points you face:
Comparison:
| Feature | Linux System Package Managers | C++ Package Managers |
|---|---|---|
| Main Purpose | Manage operating system and applications | Manage C++ libraries and dependencies |
| Package Scope | Broader: system tools, apps, libraries | Narrower: C++ libraries |
| Focus | Stability, security, compatibility | Ease of use, flexibility, dependency management |
| Pre-built Binaries | Yes | Yes, but also often offer source code |
| Dependency Management | Limited | Advanced, can handle complex scenarios |
| Multiple Versions | Limited | Often offer multiple versions and configurations |
| Community and Resources | Large and established | Varied, some larger, some smaller communities |
The best choice depends on your specific needs:
Remember, these categories aren't mutually exclusive. You can use both types of package managers in your workflow depending on your needs.
]]>By prioritizing testing a comprehensive list of configuration during CI, your team can unleash access to new features and tools, boosting productivity and ensuring project longevity and compatibility in a competitive landscape by establishing guardrails for the project.
Let's delve deeper into the compelling reasons why this DevOps approach, centered around building more configurations, deserves widespread adoption in C++ environments.
As with C++, the Golang's runtime is backwards compatibility. Older binaries typically run seamlessly on newer Go versions without recompilation. This helped establish the best practice of thoroughly testing applications with multiple Go versions. In CI pipelines, running automated tests against multiple Go versions looks something like this:
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
go: [ '1.21', '1.20', '1.19' ]
name: build (go-${{ matrix.go }})
steps:
- uses: actions/checkout@v4
- uses: actions/setup-go@v5
with:
go-version: ${{ matrix.go }}
- run: go build app.go
The key concept to note is the strategy, pun intended, which has the matrix, a declarative list, of Golang versions to test against. Go's approach can inspire similar practices in C++. All the popular CI services offer this feature (just with unique names).
At a high level, it's easy to think of this as a template<typename version> class where multiple instance of the job are instantiated each with a different version but perform the same algorithm and can be parallelized.
The best strategy to identify the "version matrix" is looking at the platforms your project already supports. At a minimum that should be your LTS, production (latest release), and current build tools. This will help ensure any changes introduced will be compatible across the board. Building and testing the product with a newer toolchain will help build confidence with business stake holders as operation risk will be reduced.
The unified tool set behind Go is amazing, however competition is healthy and drives innovation for end-users. Let's do something similar to go version but try it with C++ compilers and language standards.
strategy:
matrix:
compiler: [g++-12, clang-15] # Specify compiler versions to test
cxxstd: [17, 23] # Specify the language standard to test
You can the configure you build system normally.
steps:
- run: cmake --preset release \
-DCMAKE_CXX_COMPILER=${{ matrix.compiler }} \
-CMAKE_CXX_STANDARD=${{ matrix.cxxstd }}
The full workflow is over on Gist. It's a great idea to apply this idea to sanitizer presets.
And there is no reason for this to not be cross-platform. Though for GitHub Actions, this is a little bit more involved since not all the C++ build environments are installed.
This should give you a good idea how you can tailor a strategy.matrix to your specific needs.
test:
runs-on: ${{ matrix.os }} # Use dynamic runner based on OS
strategy:
matrix:
os: [windows-latest, ubuntu-latest, macos-latest]
compiler: [gcc-11, clang-14]
include:
- os: windows-latest
compiler: gcc-11
# Add extra fields to `choco install mingw-w64-x86_64-gcc-11``
name: mingw-w64
version: 11.2.0
- os: windows-latest
# Override `clang-14` to use the MSVC provided clang
compiler: cl-clang
- os: macos-latest
compiler: gcc-11
# Add extra fields to `brew install` the correct version
package: gcc@11
The full workflow can be viewed as a Gist.
Incorporate these principles into your CI practices! Here's a few steps to get you started
Designing a flexible CI pipeline with a variety of configurations breaks down barriers to adding new compilers. Staying up-to-date is essential for efficient software development, and comprehensive configuration testing ensures code quality, performance, and security from the outset.
]]>C++ teams often struggle with an extensive list of build systems, introducing layers of complexity. CMake, when mastered, becomes a game-changer. This blog focuses on CMake's key pillars: toolchains, presets, and build scripts. Understanding their roles and interactions is crucial for achieving a streamlined developer experience and unambiguous CI workflows.
Join us on a journey where we'll:
In this blog, we'll apply SOLID design principles to our build scripts, focusing on the distinction between tool configurations, global project settings, and target-specific options. This effective design allows for supporting multiple build environments without the need to change CMakeLists.txt for each of them.
While new tools like XMake are promising, the blog predominantly focuses on CMake, given its prevalence in over 85% of development teams. For those starting new projects under research and development efforts, exploring alternative options like Meson is recommended.
Understanding the distinction between toolchains, presets, and build scripts is vital. Let's break down these three layers:
my_toolchain.cmake) and pass it to CMake using presets.CMakePresets.json or CMakeUserPresets.json file, define presets, and use the --preset option with CMake commands.CMakeLists.txt files in your project's root and subdirectories.With a single responsibility, toolchains focus on compiler and tool setup for specific environments. They are essential for cross-compilation and non-standard tool setups.
Example for Cross-Compiling:
build:
matrix:
toolchains:
- my_toolchain_arm.cmake
- my_toolchain_x86.cmake
run: |
cmake --preset release -DCMAKE_TOOLCHAIN_FILE="${{ matrix.toolchain }}"
cmake --build --preset release
uses: upload-artifacts@v4
with:
name: ${{ matrix.toolchain }}
paths: build/release
Example for Supporting Multiple Compilers:
build:
matrix:
compiler:
- { "c": "gcc-7", "cxx": "g++-7" }
- { "c": "gcc-11", "cxx": "g++-11" }
- { "c": "gcc-12", "cxx": "g++-12" }
run: |
cmake --preset test \
-DCMAKE_C_COMPILER="${{ matrix.compiler.c }}"
-DCMAKE_CXX_COMPILER="${{ matrix.compiler.cxx }}"
cmake --build --preset test
cmake --build --target unit_tests_run --preset test
It's entirely possible to define a preset for each configuration. This however posses significant challenges when configurations need to change over time or when downstream consumers desire different configurations. A reasonable compromise would be to make toolchain specific presets hidden: true to prevent their misuse.
Effective organization of presets enhances manageability and scalability. Follow a structured approach to organizing presets for different scenarios.
Example Preset Organization:
.
├── cmake/
│ └── CMakePresets.json
├── include
├── src
├── examples/
│ └── CMakePresets.json
├── tests/
│ └── CMakePresets.json
├── CMakePresets.json
└── CMakeUserPresets.json
It's import to keep presets open for extension, but closed for modification. You should not be be redefine or overriding values.
CMakePresets.json: Define baseline configurations for consuming or developing the project.cmake/ Directory Presets: Include presets for the entire project.examples/ and tests/ Directory Presets: Include presets specific to those targets.This concept also extends to monorepos, each sub component could define it's own set of presets that are aggregates but the root presets. Simply substitute in core/ and driver/ or error/ and math/ to match your use case.
Including other CMakePresets.json:
{
"version": 6,
"cmakeMinimumRequired": {
"major": 3,
"minor": 25,
"patch": 0
},
"include": [
"example/CMakePresets.json",
"tests/CMakePresets.json"
],
"configurePresets": [ /* ... */ ],
"buildPresets": [ /* ... */ ]
}
Presets should not be forced to depend upon configurations that they do not use.
Most of the preparation needs to happen in configure presets. It's important to also create build preset with the same name.
cmake/CMakePresets.json:
Define simple unobtrusive presets that can be inherited for more specialized. By setting a configuration preset to define the build folder, you will not need to call mkdir and you can reuse the preset name to access artifacts.
{
"name": "release",
"configuration": "Release",
"binaryDir": "${sourceDir}/build/${presetName}"
}
tests/CMakePresets.json:
Declare configurations that produce unique binaries with a narrow focus. Passing in all the global compiler flags and define the required environment variables for either configure or build.
{
"name": "asan",
"inherits": "debug",
"cacheVariables": {
"CMAKE_CXX_FLAGS": "..." // Global compiler files needed by all targets for complete results
},
"environment": {
"ASAN_OPTIONS": "..." // Configure EVN_VAR required to active more checks
}
}
Refactor CI pipelines to leverage the simplicity and power of CMake presets.
Example CI Pipeline for Release:
Remove the hassle of having the correct working directory.
build:
run: |
cmake --preset release
cmake --build --preset release
uses: upload-artifacts@v4
with:
paths: build/release
Example CI Pipeline for ASAN (AddressSanitizer):
Setup custom "run" targets to launch tests with the correct environment variables to ensure consistency without polluting the workspace.
build:
run: |
cmake --preset asan
cmake --build --preset asan
cmake --build --target unit_tests_run --preset test
Flexibility is crucial. Allow developers room to work efficiently while ensuring a green production environment. Use CMakeUserPresets.json for user-specific configurations.
Example User-Specific Preset (CMakeUserPresets.json):
{
"name": "clang",
"inherits": "debug",
"generator": "Ninja",
"cacheVariables": {
"CMAKE_C_COMPILER": "clang-16",
"CMAKE_CXX_COMPILER": "clang++-16",
"CMAKE_CXX_STANDARD": 23,
"CMAKE_CXX_CLANG_TIDY": "clang-tidy-16;fix"
}
}
Example Platform Specific Preset:
{
"name": "ccache-linux",
"hidden": true,
"cacheVariables": {
"CMAKE_C_COMPILER_LAUNCHER": "/usr/bin/ccache",
"CMAKE_CXX_COMPILER_LAUNCHER": "/usr/bin/ccache"
},
"condition": {
"type": "equals",
"lhs": "${hostSystemName}",
"rhs": "Linux"
}
},
{
"name": "ccache-darwin",
"hidden": true,
"cacheVariables": {
"CMAKE_C_COMPILER_LAUNCHER": "$env{HOMEBREW_PREFIX}/opt/ccache",
"CMAKE_CXX_COMPILER_LAUNCHER": "$env{HOMEBREW_PREFIX}/opt/ccache"
},
"condition": {
"type": "equals",
"lhs": "${hostSystemName}",
"rhs": "Darwin"
}
}
Explore other opinions and insights on CMake presets:
Explore IDE integrations and their support for CMake presets:
Are you ready to optimize your CI pipelines and enhance your development workflow with CMake presets? Let the journey begin!
]]>Let's walk through adding Ansible to handle configuring a Windows virtual machine. These ideas apply to Unix environments as well but we can tackle those in a future post. Once we've gained control over our build environments, we can tackle availability and scalability by introducing Terraform to help provision and initialize new Windows instances in Azure. This two prong solution enables both a path for migrating to the cloud and establishing a hybrid setup.
Let's get setup! To set up, start with a freshly-provisioned, fully patched VM from IT. Enable WinRM using a Group Policy Object for seamless remote management. If you are not connecting to a domain, follow the Ansible Setup Guide. Ansible's Windows support, coupled with its extensive library of built-in modules, streamlines configuration, often eliminating the need for manual PowerShell commands.
With that done, make sure to install Ansible and prepare to use it's Windows support. You'll need to add Chocolatey to Ansible support since it's not included by default, simply running ansible-galaxy collection install chocolatey.chocolatey will do the trick.
With everything setup, you are ready for the exciting bits (or bytes).
The various operations that are required to configure the machines are organized into Playbooks. With these we can specify a host with a list of tasks we want to execute. This declarative approach allows you to easily specify the final state.
We are going to focus on a cross-compiled applications whose toolchain focuses on Mingw-64 environment where developers primarily work with CMake and Ninja.
Let's make a playbook.yml!
- name: Install software on Windows machine
hosts: windows_vm
vars:
# There's lots of authentication options to pick from
# https://docs.ansible.com/ansible/latest/os_guide/windows_winrm.html#winrm-authentication-options
ansible_user: username
ansible_password: password
tasks:
- name: Install C++ dev tools using Chocolatey
win_chocolatey:
name: "{{ item }}"
state: present
loop:
- mingw
- cmake
- ninja
This playbook will install Chocolatey if it's missing and then loop over the list of tools we provided. Running a playbook is simple, just run ansible-playbook playbook.yml.
Ansible has a "check mode" feature which is incredibly powerful to help prevent configuration drift.
This is incredibly important if the build nodes are persistent and re-used for different CI/CD jobs; as scripts ran during the build process can modify the environment and have unintended consequences.
This can be done with the same playbook by calling ansible-playbook --check playbook.yml which used to verify the integrity.
This can be scaled very easily with an inventory of hosts broken into groups which can be references as a whole. Making workflows like applying security updates to all the nodes seamless.
Easy enough.
In order to streamline setting up developer systems we are also going to include Visual Studio Code with a few extra extensions installed. For this we can going to add WinGet to the mix. This tool is the client to the Windows Package Manager service simplifies installing many Microsoft tools as well as popular software like video conferencing applications. For extra points with the developers, we are going to include their favorite VSCode extensions.
- name: Install WinGet
win_chocolatey:
name: winget-cli
state: present
- name: Install C++ IDE using WinGet
win_shell: |
winget install -e --id "{{ item }}"
loop:
- Microsoft.VisualStudioCode
- Microsoft.VisualStudio.2022.Enterprise.Preview
- name: Run PowerShell script
win_shell: |
$script = @"
# PowerShell script to activate and install software
Write-Host "Activate MSVC Enterprise 2022..."
"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\StorePID.exe" AAAAA-BBBBB-CCCCC-DDDDD-EEEEE 09660
Write-Host "Installing VSCode Extensions..."
code --install-extension ms-vscode.cpptools-extension-pack
code --install-extension ms-vscode.cmake-tools
Write-Host "Verifying Installed Extensions..."
code --list-extensions --show-versions
"@
Invoke-Expression -Command $script
One thing to take note is we can very easily run powershell scripts native on the machine. This gives use the flexibility to run extra commands like activating Visual Studio with our product key. Extra care is be needed if you want to preserve --check-mode when directly running powershell cmdlets.
With that, we can setup (and update) developer environments with all the tools they require while allowing verification that the correct tools are installed to prevent drift.
For DevOps precision, meticulous version control of tools and dependencies is non-negotiable. It ensures a uniform environment across the development team, preventing compatibility issues and unpredictable behavior. The ability to pinpoint and manipulate specific versions empowers teams to troubleshoot and deliver software with a robust foundation.
Since we are using two different tools, we'll need to solve it for each of them respectively.
Going in order, we'll update Chocolatey to loop over the name and version we want to install and enable the pinned feature to prevent upgrades. Playbooks support YAML syntax which allows use to have custom JSON objects with individualized properties for our use case.
tasks:
- name: Install C++ dev tools using Chocolatey
win_chocolatey:
name: "{{ item.name }}"
version: "{{ item.version }}" # Exact version
pinned: true # Only explicit upgrades
state: present
loop:
- { name: 'mingw', version: '13.2.0' }
- { name: 'cmake', version: '3.27.9' }
- { name: 'ninja', version: '1.11.0' }
- { name: 'winget-cli', version: '1.6.3482' }
As these are the tools used to make the final produced shipping to customers that we are testing with we want to make sure these are exactly same every single time.
Tackling WinGet, we'll use the pin command. Though Chocolatey has some support for version ranges, WinGet's is more complete and since it's only used for the developer tools, we can install the latest patch version with confidence.
- name: Install C++ IDE using WinGet
win_shell: |
winget pin add -e --id "{{ item.name }}" -v "{{ item.version_range }}"
winget install -e --id "{{ item.name }}"
loop:
- { name: 'Microsoft.VisualStudioCode', version_range: '1.76.*' }
- { name: 'Microsoft.VisualStudio.2022.Enterprise.Preview', version_range: '17.6.*' }
Declarative code is often more concise and easier to read. Developers can focus on the desired result rather than navigating through detailed step-by-step instructions. Changes can be made to the underlying system or logic without altering the overall structure of the code. With less emphasis on explicit instructions, there's a reduced chance of introducing errors due to misunderstandings or misinterpretations of imperative commands.
For longevity, this separation between infrastructure and toolchain will help if you decided to transition to a Platform Engineering approach with an IDP (internal developer portal) for example.
Doing so is simple, we can run choco export packages.config to generate a list of dependencies.
This will give us a manifest of all the tools installed on the system.
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="mingw" version="13.2.0" />
<package id="cmake" version="3.27.9" />
<package id="ninja" version="1.11.0" />
<package id="winget-cli" version="1.6.3482" />
</packages>
For this example, the windows packages from WinGet are not critical for production builds, as such we'll skip those, but you are more then welcome to read their documentation for install --manifest.
Here are the key advantages of incorporating cloud instances into a hybrid build infrastructure setup:
It is possible to setup Windows VMs on Azure with both Terraform and Ansible, however this can be fairly involved. Here are some resources if you want to pursue that route.
Writing your own a provider to create a new Azure VM. Taking an extra step to join a domain or this alternative method.
Using a playbook to create an Azure Windows VM with some extra options in you need them as well as joining a domain.
Thankfully, there's a flourishing community around Terraform Windows Azure support and there are providers that can help make this very easy.
provider "azurerm" {
# Your Azure credentials
features {}
}
module "virtual-machine" {
source = "kumarvna/virtual-machine/azurerm"
version = "2.1.0"
# define resource group and subnet
virtual_machine_name = "win-machine"
os_flavor = "windows"
windows_distribution_name = "windows2019dc"
virtual_machine_size = "Standard_A2_v2"
admin_username = "azureadmin"
admin_password = "P@$$w0rd1234!"
instances_count = 1
nsg_inbound_rules = [
{
name = "winrm"
destination_port_range = "5986"
source_address_prefix = "*"
},
]
}
module "domain-join" {
source = "kumarvna/domain-join/azurerm"
version = "1.1.0"
virtual_machine_id = element(concat(module.virtual-machine.windows_virtual_machine_ids, [""]), 0)
active_directory_domain = "myorg.com"
active_directory_username = "azureadmin"
active_directory_password = "P@$$w0rd1234!"
# Required TAGs for Azure resources
}
Now you can run Ansible normally with ansible-playbook -i '${terraform.virtual-machine.windows_vm_private_ips},' playbook.yml or you can add it as an extra step to the main.tf with:
provisioner "local-exec" {
command = "ansible-playbook -i '${virtual-machine.windows_vm_private_ips},' playbook.yml"
}
For a comprehensive understanding, let's address some additional aspects.
By embracing Infrastructure as Code (IaC), like Ansible and Terraform show in the post, you can empower your C++ build infrastructure with:
Take control of your C++ build process today. Embrace IaC and unlock the agility, efficiency, and scalability you need to deliver software faster and with greater confidence.
]]>The 2023 ISOCPP Survey echoes the sentiments of C++ developers grappling with key issues:
DevOps, championing artifact management through tools like Maven, npm, and Cargo, unveils a canvas for addressing C++ dependency challenges. Specialized package managers such as Vcpkg and Conan offer a structured approach to managing libraries, automating retrieval and configuration. Ensuring the exact dependencies (both external open source or third-party and internal to a project) are consistently tracked and can be reproducibly installed is a well established best practice. Through modular software design and "microserviceslibraries", C++ developers can distribute builds to enhance parallelization and fostering a streamlined development lifecycle.
The heartbeat of DevOps is a robust monitoring and feedback loop, powered by tools like Prometheus and Grafana. For C++ developers, tracking performance metrics and build data is pivotal. Techniques such as analyzing data from gcc -ftime-report or clang -ftime-trace offer insights into the impact of changes, identifying trends enabling teams to proactively resolve issues. Increasing the granularity of the build graph and each step (configure, build, and test) can help isolate problems making the overall challenge less overwhelming. This continuous feedback loop ensures a seamless user experience and efficient CI operations.
DevOps principles, particularly those of Continuous Integration/Continuous Delivery (CI/CD), are catalysts for streamlining build processes. CMake, a cornerstone in the C++ ecosystem, simplifies build script complexities with features like Presets and Workflows. However, caution is advised against tightly coupling Build Scripts with Build Environments; Build scripts are software too and principals like cohesion and coupling still apply. Alternatively for a encompassing solution, innovative tools like Xmake, Meson and Bazel are introducing features for dependency management, build orchestration, and scalability. Make sure to have a clear delineation between build environments and their toolchain, global configuration variant, and target specific compiler flags when refactoring your code.
DevOps extends its embrace to traditional IT operations, where technologies like Infrastructure as Code (IaC) take center stage. Terraform and Ansible automate infrastructure provisioning and configurations with routine checks to prevent configuration drift, ensuring deployable build environments are robust and compliant. When reproducible builds are top of mind, having ephemeral build environments that can scale with elasticity is a key DevOps best practice to rely on. Leverage orchestration tools to ensure availability by provisioning the correct version controlled build environments. With the adoption of system package managers, a staple in the *Nix ecosystems with counter-parts like Chocolatey and WinGet on Windows, aligning with the ethos of reproducible builds. Ensure you treat your tools like dependencies with proper version control and artifact management.
As the C++ ecosystem navigates challenges, DevOps emerges as the guiding force, offering not just solutions but a cultural shift toward collaboration, automation, and continuous improvement. The synergy of Artifact Management, IaC, and PaaS technologies positions C++ developers on the cutting edge of a transformative journey. In this DevOps odyssey, the challenges of today become the stepping stones to a more efficient, scalable, and resilient tomorrow. Embrace the revolution, and let DevOps redefine your C++ development experience.
]]>Today, we navigate the intricate landscape of C++, delving into how the DevOps approach aligns seamlessly with both historical and contemporary roles within the ecosystem. It becomes apparent that DevOps best practices hold the key to unlocking solutions for some of the most prevalent challenges faced by C++ developers.
Critics, such as Scott Willson, correctly predicted back in 2015 the far-reaching scope of DevOps, encompassing best practices, behaviors, and tools across various disciplines involved in the entire software development lifecycle. The essence is not about overburdening developers but applying good software practices universally, as exemplified in talks like "Chef, test-kitchen, Docker, CI, Oh My!" from DevOps Day Toronto back in 2015. This philosophy transcends individual roles, emphasizing a comprehensive and collaborative approach. Software design principals likes Coupling and Cohesion should also apply to how we manage build environments.
DevOps emerged in 2010 as a response to the challenges posed by Agile methods, eventually leading to the realization that faster software delivery could unlock competitive advantages. The State of DevOps reports from 2018 underscored this, highlighting the strategic edge gained through accelerated software delivery. In 2023, the momentum has shifted towards Platform Engineering, reflecting the evolving expectations for collaboration post-pandemic.
While skepticism exists about the necessity of DevOps for C++ development, some argue that it conflicts with the language's low-level programming focus and misconceptions that DevOps is exclusively for cloud deployment. This perspective views specialized DevOps roles as potentially distracting from the core development work.
However, despite reservations, there's a compelling acknowledgment that certain challenges faced by C++ developers undeniably fall within the DevOps domain. Managing dependencies, a persistent issue in C++ development, becomes increasingly complex as projects scale. Yet solutions to this problem can be traced back to 2017. DevOps practices, particularly those executed by Build and Release Engineers, provide solutions for dependency management, version compatibility, and maintaining consistent build environments.
To illustrate the monumental potential for efficiency gains, consider the integration of DevOps principles like CI/CD with the addition of Workflow Presets in the ubiquitous build system tool CMake. This new feature can be a cornerstone in simplifying build script complexities. The recent introduction of innovative tools like Spack, Xmake, and Tipi building upon the success of Conan and Vcpkg further amplifies these gains, addressing challenges in dependency management. Build orchestration and scalability is another area where pioneering tools like Bazel and IncrediBuild have seen huge success reducing build times across the ecosystem.
The demand for highly specialized roles, such as Build and Release Engineer, C++ Build Tools Engineer, and Build Automation Engineer, remains high within the C++ ecosystem. The 2023 ISOCPP Survey reported 73% of developers struggle with setting up CI pipelines, with eight identified problems falling under the DevOps umbrella. Recognizing this, it becomes evident that the DevOps toolkit offers specialized tools and best practices aimed squarely at solving these pervasive problems.
In conclusion, while skepticism may linger, there's an increasing acknowledgment that integrating DevOps practices and technologies into the C++ development landscape is not just a choice; it's a strategic necessity. C++ DevOps is not solely a technical evolution; it's a cultural transformation that unites developers, QA professionals, and operations teams. Embracing C++ DevOps becomes indispensable for organizations aspiring to thrive in the ever-evolving and competitive software development landscape.
]]>