Rust SIG Meeting - 2026-02-17 #14

PLeVasseur · 2026-02-17T14:59:25Z

PLeVasseur
Feb 17, 2026
Collaborator

Hey folks 👋 welcome to our third meeting of 2026.

Rust SIG Meeting 2026-02-17

Agenda

Solicitation of notetaker
- @PLeVasseur
Rust Watercooler Chat Topic - Rust + Bazel; Eric McBride - Toyota Connected North America
Review GitHub repo content and discuss how to enrich (Pete)
1. Issues
2. Discussions are now active! We'll take meeting notes here based on previous agreement in the SIG.
Office hours - Rust + Automotive questions - come chat! (All)
Discuss upcoming events / news related to Rust & Automotive (All)
Meeting close

Check-in area

(20 participants max at once, didn't catch everyone's GitHub handle)

Housekeeping section, please add

Document space: https://drive.google.com/drive/folders/1Ub0qTLKvTFilPC9TFVEdTyWn_9qJ-vYD?usp=drive_link
GitHub repo: https://github.com/rust-sig/rust-sig
Eclipse SDV Slack channel: #rust-sig

Tasks

<task>

Meeting Minutes

Eric McBride - TCNA: Bazel + Rust

Non-safety-critical software; from "Hey Toyota" all the way back to the customer

Using Bazel for easier monorepo integration of many different languages and ways of getting them to communicate

Exploratory: Python; Production: Rust

Haskell to Rust to C bindings too

Performance in CI was a huge factor for reaching for Bazel

Rust's shining features like proc-macros / feature flags become painful

god crates and remote cache could not save them

instead of granular common crates had one god crate with many of the common types used many places

Focused on interface first which were common for crates and then

Bazel concept: aspect - run code on top of build path to make sure no leaks and misimports

Was able to turn internal dependencies into a tree rather than a web
able to break up god objects

Using Bazel platform / toolchains with rustc_flags set in them to coordinate regions / generation, e.g. between JP / NA

Custom LLVM toolchains lets sysroot linking be super easy for developers. No need for devs to deal with downloading sysroots, this "just works".

bazel-diff: allows for generational aware diffs even on the same codebase, and maintain old generate on branch which is frozen. Can allow for juggling multiple generations of product.

bazel_env: adds binaries onto path when changing into repo. bazen run of env command will install all tools needed for devs, e.g. jq, qemu

bazelisk: "the cargo of bazel"

cargo_env uses bazel_env, takes one step further imagine if also managing e.g. sysroots

allows to reuse those things
makes cargo hermetic in a way

Bazel cons:

"Higher learning curve than Rust"
Need to know the nitty details of how the package manager works in each language.
Python uv rule set is great
rules_rust works good, has had too contribute quite a bit; been fine
- when messing with crates universe ruleset gets rough
- rules_rs forked version of rules_rust has been quicker to merge PRs
- rules_rs works fine on the TCNA monorepo, faster than crates universe; hasn't switched yet
need dedicated build team; some folks recommend ~15% of workforce dedicated to making the build experience work well
only use Bazel if really needed, only if > 500k LoC

umaucher

C++ & Python, basic stuff is not that bad
using aspects, really optimizing things is hard, seems like it happens with most things
likes Bazel since it leads to some best practices
~6 years or so back did the Python transition in Bazel
- Bazel had to change a lot as Python changed
- Thinks this is probably going to be the same for Rust
- Seems to be a common challenge / issue with those languages with

Daniel:

Rust build system seems more stable/reliable than uv
Curious to understand how Bazel compares to buildstream
- Eric: mise is good, but not hermetic. Good way to get away from bash scripts
- Analyzed Buck, etc, landed on Bazel due to support
- mise is good for exploratory work e.g. AI/ML work happening in different repos like pinning to certain versions; people were checking out separate versions and causing issues

Andreas:

devcontainers in heavy use for development tooling to ship around
do you rely on devcontainers at all?
Eric: Use macs, not linux machines. Have QEMU runtime. Issues with containers with real-time requirements for mic streaming. Whenever trying to pipe frames to/from containers end up with dropped frames. Understand the usage of devcontainers, but end up building cross-compiled to whatever target is needed.

Dillon:

Other dev experience tools?
Eric:
- Had to write custom patchelf extensions for Yocto builds. This was not supported well with the symlinks used binaries. So had to force this sort of work to make work well Bazel. patchelf Bazel macro to wrap this up.
- Use Buf for protobuf generation. Don't mind about protobuf gen being hermetic since these are versioned.
- Artifactory extension to support directory crawling and lockfile to avoid redundant refetches
- Bazel tests need shared objects that present well in Bazel, dynamic linking into tests. Trying to create centralized place for this.

Why hermetic builds?

many platforms to support between NA and JP for developers
"it works on my machine"
NA owns the build system, but JP and India wake up when NA is asleep and need things to work
"becoming a principal engineer means either build engineer or diagram engineer"
saves a lot of money to avoid pushing to CI to avoid testing

Stuff coming up for Rust

Rust Nation UK
Rust Week
Automotive Computing Conference US 2026
Next week Bon in Germany Eclipse SDV event
2nd Week of April: Eclipse big event: OCX

Requested topics

ASIL B-D: What would this dev environment look like?

maybe Florian Gilcher can come in

iceoryx2

Maybe Matthias or Christian

Ankaios

Kaloyan
Using devcontainers on WSL on Windows
Don't have any certs or any issues with that
Cross-builds are not the problem; building devcontainers for two platforms
- cross-compiling on WSL