Skip to content

CMake & Bazel Meetup in Munich - Recap

Fire up your time machine and set it to July 18, 2024, because we're taking a trip back to the CMake & Bazel Meetup in Munich. Let's set the scene: EngFlow and Apex.AI have joined forces to host a day filled with insightful talks and networking opportunities at Apex.AI's office in Munich.

CMake & Bazel Meetup - Jul 2024 - Munich

The CMake & Bazel Meetup in Munich

There was no shortage of great talks and knowledge, including: - Welcome and Introduction by Dhruv Chad, Apex.AI - Deploying With Bazel on Yocto-based System by Evgeny Petrov, Quello - Automatically Translating Our Bazel Codebase to CMake by Nico Morin, Apex.AI - CMake CPS: What It Is and Why It Matters by Damien Buhl, Tipi - One TOML File to Rule Them All: Official Rules for Multi-Version Multi-Target Python Setup by Michael Krasnyk, Ruumi - Until Next Time

Welcome and Introduction by Dhruv Chad, Apex.AI

Kickoff Remarks

Helen Altshuler & Dhruv Chad Kicking off the CMake & Bazel Meetup in Munich

Kicking off the evening, Dhruv from Apex.AI set the stage with a warm welcome. He shared his experience migrating Apex.AI to Bazel, touching on the challenges they faced and how this transition is shaping their work with ROS(Robot Operating System). This migration marks a big change in Apex.AI's development processes and how they interact with the ROS ecosystem. It was clear that Apex.AI isn't just adapting to the future; they're actively building it. Dhruv's talk set the tone for the evening, leaving us all eager to dive deeper into the world of modern build systems.

Deploying With Bazel on Yocto-based System by Evgeny Petrov, Quello

Evgeny Petrov from Quello took us on a wild ride. As the developer, producer, and operator of charging stations (talk about electrifying work), Evgeny presented his team's adventures in using Bazel for Rust embedded development. He outlined the hurdles they faced: dealing with third-party dependencies in Yocto images, the complexities of building system images in a monorepo, struggles of making everything work together in a monorepo, and the dance of cross-compilation configurations.

He shared their clever approach to solving these problems: a step dedicated to building Yocto images that's only triggered upon request, using a C++ toolchain not built by Yocto (due to integration challenges), and configuring Bazel for cross-compilation. His talk was a testament that with determination, even the most complex build system puzzles can be solved.

Automatically Translating Our Bazel Codebase to CMake by Nico Morin, Apex.AI

See the slides

Automatically Translate Bazel Codebase to CMake

Nico Morin presenting at the CMake & Bazel Meetup in Munich

Nico Morin took the stage and shared how Apex.AI got Bazel and CMake to play nice. He began by outlining the challenges faced: despite their migration to Bazel, Apex.AI still needed to support CMake to meet customer expectations and maintain compatibility with ROS2 — without impacting maintenance efforts. So, how did they pull off this magic trick?

They developed an automated system to bridge the gap. By running Bazel aspects across their codebase, they collected the necessary build details — such as inputs and outputs for binaries and libraries. Using this information, they programmatically generated CMake files that mirrored their Bazel configurations. By implementing this automation it allows them to maintain Bazel as the single source of truth while still supporting CMake for customer-facing needs.

The result? A hybrid system where customers can choose to work with either CMake or Bazel, offering flexibility without sacrificing developer productivity or sanity.

CMake CPS: What It Is and Why It Matters by Damien Buhl, Tipi

Next, Damien from Tipi stepped up to introduce Common Package Specification (CPS). He presented us with an in-depth look. And he didn't stop there, he even demoed how they've implemented it.

CPS is a community effort to bring CMake Package Config files into a declarative format. With the potential to replace CMake Package Config in the future, CPS aims to fix how dependencies will be resolved. Best of all? It's not just for CMake — Bazel could use it too.

Damien gave a behind-the-scenes look at how to implement CPS on top of CMake's package configuration files. This approach allows for unheard-of optimization, building dependent code while dependencies are in the process of building, and only synchronizing at the link phase.

One TOML File to Rule Them All: Official Rules for Multi-Version Multi-Target Python Setup by Michael Krasnyk, Ruumi

See the slides

One TOML File to Rule Them All

Michael Krasnyk presenting at the CMake & Bazel Meetup in Munich

To wrap up the lightning talks, Michael Krasnyk from Ruumi took us on an epic journey through the intricacies of Python setups across multiple versions and target platforms, reminiscent of Frodo's trek to Mordor. His presentation addressed the challenges and solutions for managing Python deployments in complex environments.

Michael showed how he leverages Bazel with a bazel run \<target> command for deployment automation, a unified pyproject.toml file to manage dependencies, and Poetry lock files to ensure consistency across multiple platforms and Python versions. By using the pyproject.toml file, Michael's solution centralizes dependency management, including platform-specific dependencies for AWS Lambda and EC2. Poetry handles version resolution and lock files, ensuring dependencies will be correctly managed across different Python environments.

This configuration works with Bazel custom rules, such as poetry_update for resolving dependencies and py_zip for packaging Python code into ZIP files tailored for AWS Lambda deployments. This approach resulted in simpler deployment processes across AWS services by automating package creation and performing compatibility checks with the Lambda execution environment. Michael also shared an integration with PDM (Python Development Master) and UV (for virtual environments) to further streamline dependency management.

Throughout his quest, Michael slayed some dragons — from running unit test on the host machine to integrating rules_oci for containerized workflows in deployment pipelines. He also tackled the complexities of Windows environment support, managing binary dependencies, and ensuring correct versioning of packages like shapely while excluding runtime dependencies from Lambda such as awslambdaric and boto3 to avoid redundancy in the packaged artifacts.

Until Next Time

We're left with heads full of ideas and overflowing with excitement for what the future of build systems has in store. From embedded Bazel adventures to CMake — Bazel translators, from the future of CPS to TOML-powered Python wizardry, it's clear the build community is as innovative as ever.

Interested in attending or speaking at an event? We have much more coming up, so check it all out at meetup.build.