Correct, reproducible, fast builds for everyone not running Windows
https://news.ycombinator.com/item?id=9257187
If you've got the expertise to add it, sounds like it would be welcomed.
Bazel – Correct, reproducible, fast builds for everyone
61–70 of 185 posts
Re: Bazel – Correct, reproducible, fast builds for everyone
#62Is 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.
Do you have a link to that white paper? A quick search on their research site doesn't really yield any results.
Re: Bazel – Correct, reproducible, fast builds for everyone
#63What is this lameness? https://github.com/google/bazel/tree/master/third_party - 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.
Well keeping dependencies in source means no third party dependency at build time, right?
Re: Bazel – Correct, reproducible, fast builds for everyone
#64Made by the arrogant Google assholes? No thanks. I'll stick to pants.
Disclaimer: I work for TAGA (The Arrogant Google Assholes)
Re: Bazel – Correct, reproducible, fast builds for everyone
#65What is this lameness? https://github.com/google/bazel/tree/master/third_party - 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.
Tbh, if your company relies on this software, I would also make sure that it cannot just vanish - and thats the most efftive solution. Artifacts can disappear from the internet and you don't know if the downloaded stuff is still the same as before. Especially, if you look outside of the maven ecosystem, but even there you have to rely on apache and their partners. An outage can mean that you cannot deploy critical bugfixes to your platform.
Re: Bazel – Correct, reproducible, fast builds for everyone
#66What is this lameness? https://github.com/google/bazel/tree/master/third_party - 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.
Well keeping dependencies in source means no third party dependency at build time, right?
Right... but this will be an anchor on adoption. I can see why e.g. the Android build system does the same thing since it's all off in its own world anyway. I doubt you'd be popular with Linux distro packagers if you required bazel for some C library.
Re: Bazel – Correct, reproducible, fast builds for everyone
#67Is this the tool that Google uses to build its Golang source? Or is that something else which is not available?
The Golang source code for the server code at google is built with this tool. The rules that accomplish this are rather complex due to their interactions with our C++ libraries, and predates the open source "Go" tool. The experience with the Google internal rules, motivated some of the choices in the "go" tool, I believe. If you're interested, hanwen wrote a bunch rules with similar semantics as the internal rules, s…
In what cases would using Bazel make sense to build Go projects? If they're extremely large? If they have a lot of dependencies on code in other languages? If you need sophisticated build/release tooling?
BTW, thanks for the release! Will have a fun time digging through this over the next few days. I heard some murmurs that Blaze was going to be open sourced from around the watercooler but didn't think it'd be so soon.
Re: Bazel – Correct, reproducible, fast builds for everyone
#68What is this lameness? https://github.com/google/bazel/tree/master/third_party - 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.
Try not to be so rude.
The FAQ is pretty clear about their reasons. It talks about tools, not other dependencies, but I'm sure the reasoning is the same: "Your project never works in isolation... To guarantee builds are reproducible even when we upgrade our workstations, we at Google check most of these tools into version control, including the toolchains and Bazel itself."
It's a sensible policy and one I use myself. Do you have a better reason for disliking this policy than a knee-jerk "yuck?"
Re: Bazel – Correct, reproducible, fast builds for everyone
#69> Why doesn't Google use …? Make, Ninja: These tools give very exact control over what commands get invoked to build files, but it's up to the user to write rules that are correct.
> Users interact with Bazel on a higher level. For example, it has built-in rules for "Java test", "C++ binary", and notions such as "target platform" and "host platform". The rules have been battle tested to be foolproof.
But does it give the optional custom level of control that for example CMake + Ninja provide? Or it's only high level rules?
Re: Bazel – Correct, reproducible, fast builds for everyone
#70I had a bit of a read but I didn't find where it explains (code or doc) how it achieves reproducible builds. It seems like a stricter, huge make-like harness (in fact it reminds me of the mozilla firefox python build system a bit). It's not bad by any means, but it seems like to me it doesn't "magically" fix the "be reproducible" problem at all (which is what it seem to claim) Am I missing something?
Conceptually, your build results should be a pure function of your source tree. If I understand correctly, within Google, the cross-compilers are actually checked in to the source tree, so that the distributed jobs will use the same compiler to build your code. It seems like currently bazel only uses whatever is in /usr/bin though[0]. For Java compilations, bazel additionally has its own jar builder that sorts the filenames and zeros the timestamps within the zip file[1].
[0]: https://github.com/google/bazel/tree/master/tools/cpp [1]: https://github.com/google/bazel/tree/master/src/java_tools/b...