Better CMake: A World Tour of Build Systems - Better C++ Builds - Damien Buhl & Antonio Di Stefano

cppcon.org/
---
Better CMake: A World Tour of Build Systems - Better C++ Builds - Damien Buhl and Antonio Di Stefano - CppCon 2023
github.com/CppCon/CppCon2023
Recently the C++ community is all about safety and new “successors” programming languages are popping up like Cpp2, Carbon, Val and others to complement C++ towards software security and memory safety.
While it’s very beneficial to design new languages features to support safety, it is equally important to have proper tooling. One key aspect of a programming language’s usability and safety is how the code written can be shipped to end-users and how the software supply chain security can be guaranteed.
Happily the C++ community has been unifying in the last decade from various build systems on CMake. Despite it’s massive adoption it is still criticized for reasons ranging from it’s turing-completeness to the fragmentation of the different CMake styles across codebases. It also lacks important features than newer build systems provide: dependency management, SBOM (Software Bill Of Material) generation, reproducible, hermetic and remote builds.
Newer potential “successors” build systems for C++ (e.g. bpt, GN, Meson, BuildCC) but also polyglot build systems like Bazel and Gradle have been designed to overcome these issues. In this talk we will analyze which choices were made and which benefits they offer. Finally looking at how software supply chain security, static+dynamic code analysis, reproducible, hermetic and remote builds are achieved in their ecosystem.
After looking at an overview of the design decisions and benefits that these “successors” build systems provides, we will identify best practices and provide pragmatic solutions to get all of this today with CMake.
To prove our point we will finally demo SBOM generation, build reproducibility to the single byte and remote builds on a large CMake codebase.
---
Antonio Di Stefano
Antonio (@TheGrizzlyDev) is a DevEx engineer at EngFlow, his main focus is elevating the happiness and productivity of software engineers. Open Source contributor to Natalie, a fast Ruby to C++ transpiler, he spends his spare time on Snazel : the only way to get Snake and Doom run on Build Systems DSL.
Damien Buhl
Damien (alias daminetreg) co-founder and CEO tipi.build is an enthusiast C++ developer. Opensource entrepreneur, CppCon Speaker, GameMaker.fr community founder, Qt for Android contributor, Boost.Fusion maintainer since 2014.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
TH-cam Channel Managed by Digital Medium Ltd: events.digital-medium.co.uk
---
Registration for CppCon: cppcon.org/registration/
#cppcon #cppprogramming #cpp

[@krumbergify]

Really nice talk! Thanks! Learned quite a few tricks although I use many of these tools daily.

[@schneefackel7053]

> posting a talk called "Better CMake" on April Fool's Day
Well played, CppCon!

[@MatthewWalker0]

One other thing I love about Bazel is the sandboxing. You can be quite sure that you have sufficient dependencies declared, so no race conditions are possible.
It also trivially supports generating files, which is unreasonably awkward in CMake. It's also really easy to get the dependencies wrong for custom rules in CMake.

[@bloodgain]

I want automatic and fast dependency management for development, as does everyone. But ideally, I want the ability to build CPU-native versions of libraries or pull architecture-specific versions from my package repository to take advantage of advanced CPU instruction sets at optimization/release time. I don't want to wait for them to build every time, but I probably do want to rebuild them any time a library or the compiler chain is updated, or just always build them at optimization (pre-release) time.
AFAIK, no build system handles this natively. The only options I'm aware of currently are to make it a switch for custom opt/rel build rules or make (cross-)compiling your dependencies part of your CI pipeline.

[@nielsdegroot9138]

Seems to me the CPE's at 48:20 are wrong. They aren't the CPEs for the used packages. It is the CPE for the OS (Apple Mac OS).

[@daminetreg]

Yes as mentioned in the talk this is an early preview of the registry website, there is a few bugs in the version presented in the video.

[@DeckerCreek]

Hey you say pre reg but website says NO!

[@germanassasin1046]

I would rather not manipulate global variables directly, especially those that are conected to static analysis. Properties are simply better since you can enable them per target, and you still have the ability to turn them globally.

[@badassopenpolling]

Ther is no High Quality vedio available ??? its hard to read the code