[HN Gopher] Feature flags in Bazel builds
       ___________________________________________________________________
        
       Feature flags in Bazel builds
        
       Author : kaycebasques
       Score  : 29 points
       Date   : 2024-06-05 18:26 UTC (4 hours ago)
        
 (HTM) web link (pigweed.dev)
 (TXT) w3m dump (pigweed.dev)
        
       | peter_l_downs wrote:
       | 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
       | 
       | (If you're reading this, hello Keir!)
        
       | zeroCalories wrote:
       | 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 wrote:
         | 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
        
         | ein0p wrote:
         | 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 wrote:
         | 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 wrote:
           | > 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.
        
             | steveklabnik wrote:
             | This is one reason why I'm quite interested in buck2; there
             | are no built in rules at all, so if you need any changes,
             | you can just make them.
             | 
             | Unfortunately the open source set of rules is a bit rough
             | right now, with a decent happy path but a cliff if you're
             | off of it, but given some time...
        
       ___________________________________________________________________
       (page generated 2024-06-05 23:01 UTC)