[Analemma_]

Maybe, but I feel like an article I’ve read many, many times is “we hired one or more Xooglers for our startup and this turned out to be a catastrophe because they insisted on trying to bring blaze/bazel with them and it nearly destroyed the company.” It’s always bazel specifically in these articles, never any of the other internal Google stuff like Spanner.

[bbkane]

Wait please post the articles where they brought Spanner over; those sound like fun reads

[barrkel]

I mean, bazel is great and I would use it when building a codebase from scratch, but the win from switching from one build system to another is, at best, some efficiency, and you need a lot of aggregate efficiency gains to pay for effort.

[shaftway]

I was at Block and there was an interesting problem around this.

A number of Google engineers had come over, and they pushed for a way to structure the codebase where you had a ton of tiny build targets. I think a "jumbo" build target would have more than 10 files in it. Under Blaze / Bazel this would have been absolutely fine, but they were still using Gradle for their Android builds, and Gradle does not like that. Doing a build of anything meant Gradle had to initialize tens of thousands of projects. A naive engineer trying to build a single project would have to wait for about an hour for everything to be structured.

There was a big push to move everything to Bazel, and the backend and iOS teams moved over just fine, but there was someone on the Android build team who had come from Gradle, and knew a lot of techniques to cut the build time down. I remember there was a tool you would run that would examine the project structure and set up an ignorelist of projects so that Gradle wouldn't have to load projects you didn't care about.

All of the tricks were a bandaid technique at best, and eventually that engineer left the team, but the damage had been done, and migrating to Bazel was a non-starter.