If this is because Google is pushing it, two things don’t make sense to me.
- Why would you clone an open-source product because Google is pushing it?
- Why are some of the clones older than Bazel? Bazel was open-sourced on Sep 8, 2015, going by first tag, and Buck two days later, so Buck must have been in development for a while. Pants was late 2014, and Please was early 2016.
> Regarding everyone at google wanting this, before entering industry, most folks never used a proper build system at all.
Could you give an example of a “proper build system”? Even if this applies to most folks, Google hires so many people, and there are enough old-timers there (hell, Stuart Feldman was a VP of Engineering) with industry experience.
One of the fundamental problems here is that for large enough projects or multi-project repos, it becomes burdensome just to load and evaluate all of the build rules. The inevitable result is that you have to split the build rules across multiple files for different parts of the tree, and people have been doing this for decades, this is nothing new. If you look at existing build systems, there are very precious few that will actually traverse the dependency graph well across these different subinstances. Recursive make sure doesn't do this very well (see Recursive Make Considered Harmful, 1997). IDEs usually do a good job of this but they only solve a narrow set of problems to begin with.
Once you start with the goal of solving this particular problem well, my claim is that your solution will have some surprising similarities to Bazel (unless you ditch some other objective like incremental builds).
I don't even disagree with what you are saying. I just don't know if it is succeeding because of the quality of the solution, or the weight of the author.
My hunch is it is a little of both. Combined with a giant dose of not caring about existing solutions. Which is not to be scoffed at too heavily. Being able to say "I don't care" about existing users is a huge asset that any startup should not discard. One of your biggest assets is the lack of external assets to be liabilities.
Still leaves me sour to see the hubris that there is something intrinsic to this. There likely isn't.
- Why would you clone an open-source product because Google is pushing it?
- Why are some of the clones older than Bazel? Bazel was open-sourced on Sep 8, 2015, going by first tag, and Buck two days later, so Buck must have been in development for a while. Pants was late 2014, and Please was early 2016.
> Regarding everyone at google wanting this, before entering industry, most folks never used a proper build system at all.
Could you give an example of a “proper build system”? Even if this applies to most folks, Google hires so many people, and there are enough old-timers there (hell, Stuart Feldman was a VP of Engineering) with industry experience.
One of the fundamental problems here is that for large enough projects or multi-project repos, it becomes burdensome just to load and evaluate all of the build rules. The inevitable result is that you have to split the build rules across multiple files for different parts of the tree, and people have been doing this for decades, this is nothing new. If you look at existing build systems, there are very precious few that will actually traverse the dependency graph well across these different subinstances. Recursive make sure doesn't do this very well (see Recursive Make Considered Harmful, 1997). IDEs usually do a good job of this but they only solve a narrow set of problems to begin with.
Once you start with the goal of solving this particular problem well, my claim is that your solution will have some surprising similarities to Bazel (unless you ditch some other objective like incremental builds).