TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Bazel – Correct, reproducible, fast builds for everyone

625 点作者 drivebyubnt大约 10 年前

30 条评论

habosa大约 10 年前
Working at Google, Blaze is one of the technologies that amazes me most. Any engineer can build any Google product from source on any machine just by invoking a Blaze command. I may not want to build GMail from source (could take a while) but it&#x27;s awesome to know that I can.<p>I think this could be hugely useful to very large open source projects (like databases or operating systems) that may be intimidating for contributors to build and test.
评论 #9258215 未加载
评论 #9257150 未加载
评论 #9257266 未加载
评论 #9259044 未加载
评论 #9259775 未加载
评论 #9257632 未加载
评论 #9259015 未加载
评论 #9257203 未加载
评论 #9257042 未加载
thechao大约 10 年前
I&#x27;ve been burned by so many build tools over the years. I&#x27;ve finally settled (for C&#x2F;++&#x2F;asm) on the combination of Make + ccache: I build a _very_ paranoid Makefile that recompiles everything if it feels like anything changes. For instance, every rule that compiles a C&#x2F;++ file is invoked if _any_ header&#x2F;inc&#x2F;template file changes. I let ccache do the precise timestamp&#x2F;check-sum based analysis. The result is that (for large builds &lt; 10MMLOC) I rarely wait for more than a few hundred milliseconds on incremental, _and_ I have confidence that I never miscompile.<p>I just wish that I had a high-performance replacement for linking that was cross-platform (deterministic mode for ar), and for non-C&#x2F;++ flows. Writing a deterministic ar is about 20 lines of C-code, but then I have to bake that into the tool in awkward ways. For generalized flows, I&#x27;ve looked at fabricate.py as a ccache replacement, but the overhead of spinning up the Python VM always nukes performance.
评论 #9259789 未加载
评论 #9259827 未加载
latkin大约 10 年前
Correct, reproducible, fast builds for everyone <i>not running Windows</i>
评论 #9258572 未加载
评论 #9257264 未加载
评论 #9257390 未加载
评论 #9259073 未加载
评论 #9257833 未加载
评论 #9257579 未加载
评论 #9258442 未加载
评论 #9257613 未加载
评论 #9258997 未加载
ngd大约 10 年前
This is an open sourcing of Google&#x27;s internal build tool.<p>I know it as Blaze, which Bazel is an anagram of. Many files in the source have references to Blaze.
mashraf大约 10 年前
Is Google departing from just throwing white papers over the wall and let community figure out the implementation details? blaze white paper was dropped a while ago and there are already two clones in Pants and Buck at Twitter and FB. It would be interesting to see how far off clones are from original implementation.
评论 #9257837 未加载
jacquesm大约 10 年前
Getting rid of the timestamps in jar files is a huge improvement. I really hate it that when I recompile some huge java project I can&#x27;t run a checksum on the jar to verify that the build is identical to a previous run (or when being dumped into some project that my current source tree is an accurate reflection of what is running in production).
zobzu大约 10 年前
I had a bit of a read but I didn&#x27;t find where it explains (code or doc) how it achieves reproducible builds.<p>It seems like a stricter, huge make-like harness (in fact it reminds me of the mozilla firefox python build system a bit).<p>It&#x27;s not bad by any means, but it seems like to me it doesn&#x27;t &quot;magically&quot; fix the &quot;be reproducible&quot; problem at all (which is what it seem to claim)<p>Am I missing something?
评论 #9257752 未加载
评论 #9257931 未加载
评论 #9257779 未加载
评论 #9259492 未加载
评论 #9257791 未加载
评论 #9261816 未加载
yarapavan大约 10 年前
Surprisingly, significant parts of the code is not open source. According to this page, <a href="http://bazel.io/docs/governance.html" rel="nofollow">http:&#x2F;&#x2F;bazel.io&#x2F;docs&#x2F;governance.html</a>,<p><pre><code> Is Bazel developed fully in the open? Unfortunately not. We have a significant amount of code that is not open source; in terms of rules, only ~10% of the rules are open source at this point. We did an experiment where we marked all changes that crossed the internal and external code bases over the course of a few weeks, only to discover that a lot of our changes still cross both code bases.</code></pre>
评论 #9257571 未加载
评论 #9257621 未加载
评论 #9257514 未加载
评论 #9257538 未加载
cies大约 10 年前
What would be needed to get this to work with Haskell?<p>I read in the &quot;Getting started&quot;:<p>&gt; You can now create your own targets and compose them.<p>So does this mean it is a replacement for `make`? =&gt; Yes<p>Found the answer here: <a href="http://bazel.io/docs/FAQ.html" rel="nofollow">http:&#x2F;&#x2F;bazel.io&#x2F;docs&#x2F;FAQ.html</a>
评论 #9258236 未加载
w4tson大约 10 年前
It&#x27;s another impressive feat from Google and reading the comments I&#x27;ve kind of established that<p>1. Binaries are checked in to source 2. It&#x27;s more structured than Gradle 3. It&#x27;s for very large code bases 5. It&#x27;s <i>nix only<p>But...<p>1. We&#x27;ve already had the &quot;chuck it in a lib directory&quot; approach. The distributed approach maven&#x2F;ivy etc seems to be working for the millions of developers out there who just have to get through the end of the day without production going up in flames. I suppose it&#x27;s like moving a portion maven central into your code base. Checked in. Feels very odd, and kinda against one of the pillars of JVM: Maven. Love it or hate it it&#x27;s one of most mature build&#x2F;repository types out there. npm, bower anyone?<p>2. Got to agree with astral303. This isn&#x27;t really something to shout about. Better reproducibility? Gradle&#x2F;SBT have had incremental builds for quite a while. We all know there&#x27;s no silver bullet, if you don&#x27;t declare your inputs and outputs to gradle&#x2F;blaze tasks or seed with random values then you&#x27;re only going to get unrepoduceable builds.<p>3. Very large, I get that.<p>4. Very large code bases tend to enterprise systems. Enterprise systems tend to have a plethora of platforms&#x2F;OSs so it being </i>nix only is a drawback. However I suppose that if in charge of 10MLOC code base then I could mandate <i>nix only builds? However in my experience they also tend to gravitate towards standards that seem to have longevity.<p>I&#x27;m yet to give it a go so I&#x27;ll reserve final judgement. However I will say that I do wonder how far we&#x27;d be if Googles through their brightest minds at and worked with Maven&#x2F;Gradle&#x2F;SBT etc to scale their builds. (Yes I realise it&#x27;s multi-lang - so is gradle). Perhaps the whole community would benefit from performance benefits.<p>Anyway hats off Google guys. It looks impressive and no doubt I&#x27;ll jumping all over it in 12 months. In the mean time I&#x27;m off to go read up on Angular 2.0, or Typescript or ES6 or ES7 or whatever else I </i>need* to know to get me through the day.<p>Really I&#x27;m just jealous I don&#x27;t have 10MLOC code base :D
评论 #9260586 未加载
setheron大约 10 年前
If i&#x27;m sticking to primarily Java; is there a benefit to using Bazel as opposed to Maven &#x2F; Gradle &#x2F; Sbt ?
评论 #9257622 未加载
评论 #9259981 未加载
malkia大约 10 年前
Oh, but my favourite option &quot;blaze menu&quot; is missing :)
评论 #9260224 未加载
pacala大约 10 年前
A couple of questions:<p>* If I have a Maven-based project with heavy reliance on pre-built jars from Maven Central, what&#x27;s the recipe to port it to Bazel?<p>* Related, if I have multiple github repos, say a couple open source libraries and a couple private repos, what&#x27;s a good recipe in conjunction to Bazel?
评论 #9257458 未加载
评论 #9257386 未加载
mikojava大约 10 年前
Here&#x27;s the Gradle Team&#x27;s perspective on Bazel<p><a href="https://www.gradle.org/gradle-team-perspective-on-bazel/" rel="nofollow">https:&#x2F;&#x2F;www.gradle.org&#x2F;gradle-team-perspective-on-bazel&#x2F;</a>
pjjw大约 10 年前
Any reason the python support was ripped out? I&#x27;ve got my suspicions about not wanting&#x2F;not being able to properly release the python packaging method in use internally, but I&#x27;m curious if I&#x27;d be tilting at windmills to try and get it to output pexes.
评论 #9259660 未加载
评论 #9259421 未加载
cromwellian大约 10 年前
If only our code search and code review systems were public too.
评论 #9260758 未加载
pron大约 10 年前
How does it compare with Java 9&#x27;s sjavac (<a href="http://stackoverflow.com/a/26424760/750563" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;a&#x2F;26424760&#x2F;750563</a>)?<p>EDIT: I fully understand that this is a build tool for multiple languages. But its raison d&#x27;etre is speed. So I&#x27;m asking what techniques does Bazel use to accelerate builds and how do they differ from those used by sjavac, which is also designed to accelerate builds of huge projects?
评论 #9257092 未加载
评论 #9257011 未加载
Zariel大约 10 年前
Is this the tool that Google uses to build its Golang source? Or is that something else which is not available?
评论 #9257466 未加载
评论 #9257418 未加载
shmerl大约 10 年前
<i>&gt; Why doesn&#x27;t Google use …? Make, Ninja: These tools give very exact control over what commands get invoked to build files, but it&#x27;s up to the user to write rules that are correct.</i><p><i>&gt; Users interact with Bazel on a higher level. For example, it has built-in rules for &quot;Java test&quot;, &quot;C++ binary&quot;, and notions such as &quot;target platform&quot; and &quot;host platform&quot;. The rules have been battle tested to be foolproof.</i><p>But does it give the optional custom level of control that for example CMake + Ninja provide? Or it&#x27;s only high level rules?
评论 #9258013 未加载
frownie大约 10 年前
From the FAQ :<p>Multi-language support: Bazel supports Java, Objective-C and C++ out of the box, and can be extended to support arbitrary programming languages.<p>c&#x27;mon, not even the Go language from Google itself ?
jibu大约 10 年前
Maven doesn&#x27;t work so well when there are loads of small self contained &#x27;micro-libraries&#x27; (yes, sub-projects, but they are so involved to set up they almost defeat the purpose). Was considering pants -- which doesnt seem like it has great adoption? -- but this seems like its substantially more fully featured.<p>Presumably will also make opensourcing internal projects easier. That can&#x27;t be a bad thing :)
评论 #9258733 未加载
nchelluri大约 10 年前
I worked at Ning for a couple of years (<a href="http://www.ning.com/" rel="nofollow">http:&#x2F;&#x2F;www.ning.com&#x2F;</a>) and the internal codename of our create-your-own social network was Bazel.<p>When I first saw the headline I thought they&#x27;d open-sourced it.
danneu大约 10 年前
The &quot;b&quot;-with-leaves-sprouting-from-it logo is also used by <a href="http://beanstalkapp.com/" rel="nofollow">http:&#x2F;&#x2F;beanstalkapp.com&#x2F;</a>
brooksbp大约 10 年前
Will GYP&#x2F;GN be deprecated in favor of Bazel?<p>What, if any, does the convergence among these projects look like longevity-wise?
forrestthewoods大约 10 年前
Will there ever be Windows support?
hbhakhra大约 10 年前
This seems very promising. Does anyone know if this would this work with the OSGI framework?
zerr大约 10 年前
Fast - compared to what?
bubersson大约 10 年前
Wohoo! This is awesome :)
toolslive大约 10 年前
depends what you mean with reproducible: build a jar twice, and its md5sum will change because there are timestamps in the archive.
rquirk大约 10 年前
What is this lameness? <a href="https://github.com/google/bazel/tree/master/third_party" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;google&#x2F;bazel&#x2F;tree&#x2F;master&#x2F;third_party</a> - why not use gradle repos to download jars with known hashes? Sticking all those jars in the git repo is just... well, I expected better from Google.
评论 #9257921 未加载
评论 #9257878 未加载
评论 #9258005 未加载
评论 #9257851 未加载