5 ms·

Feature flags in Bazel builds

45 points by kaycebasques 2y ago

orf 2y ago
[flagged]
- usrnm 2y ago
  What other compiled language has a significantly better way of solving compile-time flags?
  - orf 2y ago
    Rust has a pretty nice setup. Definitely doesn’t require workarounds like the chromium-style build flags pattern. I’m sure there are others.
    - vlovich123 2y ago
      There’s plenty of problems in rust once you leave the happy path. For example, how do you specify a default set of feature flags based on the target? Turns out you can’t actually - you can change the flags via build.rs but unlike normal feature flags they’ll only apply to the current crate (ie it doesn’t enable anything that your feature would when enabled on the command line because the latter applies to resolution but build.rs happens later when resolution is fixed). Similarly, doing this stuff via conditionals in cargo.toml can do certain things but not others.
      - orf 2y ago
        Nothing is perfect, but a well defined and discoverable set of features, built into the language and checked for validity is great. Also having it be a feature system and not shoved into one big pre-processor soup (I.e the same thing as build time constants) is also good. Having them support groups and compose together is even better. There are other languages that improve on c/c++, but rust is just top of my mind right now.
- rfoo 2y ago
  More like, so much work to work around Bazel. It is dead simple if you don't need it to be correct.
- deleted 2y ago
  [deleted]
peter_l_downs 2y ago
Not sure I fully understand Pigweed — is it basically an open-source reimplimentation of Google's developer experience for doing firmware development? https://pigweed.dev/docs/overview.html https://pigweed.dev/docs/overview.html (If you're reading this, hello Keir!)
zeroCalories 2y ago
At what point do you bring in Bazel? I've heard some people say stuff like Python should always use Bazel, or that full stack webapps should use it, but it often just seems like extra cruft. Why not just have separate repos and use each language's tools?
- sa46 2y ago
  You'll get wildly different answers depending on who you ask. Most ex-Googlers appreciate Bazel. Folks used to ergonomic single-language builds dislike it. In my experience, Bazel works best when: - You have a monorepo. - You have one engineer who knows it in and out and can stay current. - You use several languages well-supported by Bazel (Protobuf, Go, Java, Kotlin). The benefits are a single way to build and run all tests and binaries across all languages. Bazel CI providers (BuildBuddy, EngFlow) are much nicer than YAML engineering in other CI systems. I have an old comment that's still representative of my experience: https://news.ycombinator.com/item?id=32831555 https://news.ycombinator.com/item?id=32831555
- ein0p 2y ago
  Large codebase in which you need a hermetic, repeatable, incremental build and test support. Note that in a hermetic build tests can be incremental too: if input and code do not change, there’s no need to rerun the test, and Bazel will skip it.
- ali_piccioni 2y ago
  We had an integration test that involved many tool chains and languages to prepare. Rust compilation, WASM compilation, Docker builds shell scripts that produced a VM image, Python was in there somehow too, and then a test harness, written in Rust, that took all that to actually run the test. With Bazel setup, and it was a beast to setup, developers could run all that, with remotely cached incremental builds, efficient parallel execution, and all reproducible (and same as CI) from a local developer environment with just one command.
  - riku_iki 2y ago
    > Rust compilation, WASM compilation, Docker builds shell scripts that produced a VM image, Python was in there somehow too was it through bazel rules? The worry is if some of those rules will get bug or missing necessary feature, it will be pita to deal with.

45 points by kaycebasques 2y ago

orf 2y ago

[flagged]

usrnm 2y ago
What other compiled language has a significantly better way of solving compile-time flags?
- orf 2y ago
  Rust has a pretty nice setup. Definitely doesn’t require workarounds like the chromium-style build flags pattern. I’m sure there are others.
  - vlovich123 2y ago
    There’s plenty of problems in rust once you leave the happy path. For example, how do you specify a default set of feature flags based on the target? Turns out you can’t actually - you can change the flags via build.rs but unlike normal feature flags they’ll only apply to the current crate (ie it doesn’t enable anything that your feature would when enabled on the command line because the latter applies to resolution but build.rs happens later when resolution is fixed). Similarly, doing this stuff via conditionals in cargo.toml can do certain things but not others.
    - orf 2y ago
      Nothing is perfect, but a well defined and discoverable set of features, built into the language and checked for validity is great. Also having it be a feature system and not shoved into one big pre-processor soup (I.e the same thing as build time constants) is also good. Having them support groups and compose together is even better. There are other languages that improve on c/c++, but rust is just top of my mind right now.
rfoo 2y ago
More like, so much work to work around Bazel. It is dead simple if you don't need it to be correct.
deleted 2y ago
[deleted]

peter_l_downs 2y ago

Not sure I fully understand Pigweed — is it basically an open-source reimplimentation of Google's developer experience for doing firmware development? https://pigweed.dev/docs/overview.html https://pigweed.dev/docs/overview.html (If you're reading this, hello Keir!)

zeroCalories 2y ago

At what point do you bring in Bazel? I've heard some people say stuff like Python should always use Bazel, or that full stack webapps should use it, but it often just seems like extra cruft. Why not just have separate repos and use each language's tools?

sa46 2y ago
You'll get wildly different answers depending on who you ask. Most ex-Googlers appreciate Bazel. Folks used to ergonomic single-language builds dislike it. In my experience, Bazel works best when: - You have a monorepo. - You have one engineer who knows it in and out and can stay current. - You use several languages well-supported by Bazel (Protobuf, Go, Java, Kotlin). The benefits are a single way to build and run all tests and binaries across all languages. Bazel CI providers (BuildBuddy, EngFlow) are much nicer than YAML engineering in other CI systems. I have an old comment that's still representative of my experience: https://news.ycombinator.com/item?id=32831555 https://news.ycombinator.com/item?id=32831555
ein0p 2y ago
Large codebase in which you need a hermetic, repeatable, incremental build and test support. Note that in a hermetic build tests can be incremental too: if input and code do not change, there’s no need to rerun the test, and Bazel will skip it.
ali_piccioni 2y ago
We had an integration test that involved many tool chains and languages to prepare. Rust compilation, WASM compilation, Docker builds shell scripts that produced a VM image, Python was in there somehow too, and then a test harness, written in Rust, that took all that to actually run the test. With Bazel setup, and it was a beast to setup, developers could run all that, with remotely cached incremental builds, efficient parallel execution, and all reproducible (and same as CI) from a local developer environment with just one command.
- riku_iki 2y ago
  > Rust compilation, WASM compilation, Docker builds shell scripts that produced a VM image, Python was in there somehow too was it through bazel rules? The worry is if some of those rules will get bug or missing necessary feature, it will be pita to deal with.