...it reads like one of those overly optimistic 'process optimizations' a middle manager new to the team would come up with after having a look at 'the accumulated mess'.
Maybe said middle manager moved on, with the rest of the team letting out a sigh of relief and carrying on with actually being productive ;)
In my experience migrating build systems is always way harder than you'd think because you kind of have to do it all at once, everything depends on it, and they're usually pretty hairy. Also testing them is very slow, and they're a moving target.
It's also difficult to justify time spent on it because so many people are like "but it works already".
We had a similar project at Block. Backend and iOS bit the bullet and moved to Bazel, Android development did not. Now the iOS teams are building tooling on top of Bazel and the public tools around it to have build servers, automatically remove unused dependencies, and all sorts of nifty stuff. The Android team is hacking around with Gradle, struggling just to keep the lights on and writing custom tools to work with the Gradle project structure.
It depends on your needs. I haven’t used that stack, but I maintain projects that have to use autotools, cmake and about a dozen different compilers together to build, 3 of them Fortran compilers. Bazel is easy if you have exactly one blessed toolchain, or very few, but if you need to build in any appreciable number of environments with different toolchains it’s an absolute nightmare. Perhaps this could be fixed, but it was literally years to get support for a compiler installed anywhere other than /usr/bin. It was just never meant to work with variable environments.
15 comments
[ 3.2 ms ] story [ 43.3 ms ] threadIt almost seems trite when you read "... The project took longer than anticipated ... "
Really good read if you want to look into project estimations and planning
[1] https://www.amazon.com.au/How-Big-Things-Get-Done/dp/0593239...
https://www.infoq.com/news/2020/11/android-aosp-bazel/
...it reads like one of those overly optimistic 'process optimizations' a middle manager new to the team would come up with after having a look at 'the accumulated mess'.
Maybe said middle manager moved on, with the rest of the team letting out a sigh of relief and carrying on with actually being productive ;)
It's also difficult to justify time spent on it because so many people are like "but it works already".
I wish we had gone all-in on Gradle also.