<story><title>Bazel 2.0</title><url>https://blog.bazel.build/2019/12/19/bazel-2.0.html</url></story><parent_chain></parent_chain><comment><author>malkia</author><text>One issue we hit with our CI, and mix of build systems is this - given a changelist, find out which targets needs to be built, and which one needs to be tested on pre-submit, and which on post-submit.&lt;p&gt;With that, we end up paying so much extra time building everything over and over without need, and then not building things that we ought to.&lt;p&gt;So that&amp;#x27;s one reason to switch, but at the same time lots of people simply do not get it. To them it seems intrusive, new, opinionated, and makes them not happy to use it. I&amp;#x27;ve used it for 2+ years at google, and yes initially - was WTF is this? Then it hit me... And I&amp;#x27;m sure the same is for buck, pants, please.build, gn and other similar systems.&lt;p&gt;At the end of the day, you need way to express &amp;quot;end to end&amp;quot; your build graph, from any single individual source file, shell script, or configuration downto building your executables, deploying them, etc.&lt;p&gt;It&amp;#x27;s an industry tool, that needs to be looked, and if it takes 5 people to support it, then it takes 5 people to support it, but you won&amp;#x27;t be wasting other peeople&amp;#x27;s time on issues like - &amp;quot;Why this build in the CI did not trigger?&amp;quot;, why it takes, and wastes my time (waiting for presubmit), etc.&lt;p&gt;Yes, it does not come for free, but it&amp;#x27;s worth knowing and trying it out at least.&lt;p&gt;If nothing else, here is the takeaway - Try to use a system with static graph, where relationships are known before you start building things. It&amp;#x27;s not always there, e.g. your #include &amp;quot;header.h&amp;quot; file is dynamic, but bazel forces you to express even that, and later it catches it whether you&amp;#x27;ve done it, and breaks unless it&amp;#x27;s fixed.</text></comment>
<story><title>Bazel 2.0</title><url>https://blog.bazel.build/2019/12/19/bazel-2.0.html</url></story><parent_chain></parent_chain><comment><author>habitue</author><text>Good heuristic for whether it&amp;#x27;s worth considering moving to bazel for your build system:&lt;p&gt;- Do you have 200+ developers working on a monorepo?&lt;p&gt;- Are you willing to vendor all of your dependencies and maintain their builds yourself?&lt;p&gt;If so, consider it. The productivity you&amp;#x27;re losing to unnecessary rebuilding and re-running unchanged unit tests will probably be paid back if you can contort your development process to the one Bazel expects.&lt;p&gt;If you&amp;#x27;re a small shop, the benefits Bazel is going to provide over, say, Make (or whatever standard build system your primary language uses), are going to be minimal. And the overhead of maintaining Bazel is going to cost you a ton of developer time you may not be able to afford.</text></comment>