Guidance on Build Settings vs. Platform/Constraints

257 views
Skip to first unread message

Mark Schulte

unread,
Aug 31, 2021, 1:12:08 PM8/31/21
to bazel-...@googlegroups.com
Hi All,

I'm looking for some guidance on when to use build_settings and when to use platforms/constraint_values/constraint_settings.

I'm working on a C/C++ firmware code base. I'd break my configurations into two groups.

First, hardware configurations. We support a variety of different hardware, where different hardware can mean: microcontrollers with varying architectures, circuit boards with similar microcontrollers but very different devices connected to those microcontrollers, or similar circuit boards and microcontrollers, but have very different purposes.

Second, software configurations. For example, we may have a bootloader and application that are compiled for the same microcontroller. The bootloader we'd like to be as small as possible, so it may want a "lite" version of a cc_library, whereas the application for that microcontroller may want the "full" version of the same cc_library. (i.e.: A logging library that has color printing in the "full" version, put does not support color in the "lite" version).

My current thought is: Hardware configurations should go into platforms. Software configurations should be build_settings.

Questions I'm looking for feedback on:
First, is this the intended split of platforms and build settings? Or would a different split make more sense?
Second, how can I make bazel build //... build everything? I would assume using transitions, but using transitions is a bit clunky, as I need to go and add every build setting I want to change to the transition rule to be able to configure my build properly.

Thank you!
Mark

ai...@google.com

unread,
Aug 31, 2021, 1:31:32 PM8/31/21
to bazel-discuss
Your split sounds about right.  There is so much variation in embedded hardware that you do want to make platforms for each.

You are also right about the transitions for "build everything".  A common technique is to have a rule that contains a list of items to vary on a build setting, then have it fork of to several transition branches.  When you have lots of variations and you want to easily build them all, you are going to have to express that. It's either a script that loops over command line changes, or expressing the transitions in code.

Mark Schulte

unread,
Aug 31, 2021, 6:05:04 PM8/31/21
to bazel-discuss
Great, thank you for the input! I'll give that a shot and see how it plays out!

Mark

Fredrik Medley

unread,
Sep 3, 2021, 6:55:11 AM9/3/21
to bazel-discuss
Just citing https://groups.google.com/g/bazel-discuss/c/EJIk-SViZ7Y/m/B7owh-MvCAAJ

---
We generally recommend trying to stay pure to the intention of platforms: something belongs in a platform if running the same build on two different machines might produce different results ("exec platform" differences) or running the same built binary on different machines produces different output ("target platform" differences).
---

/Fredrik
Reply all
Reply to author
Forward
0 new messages