Live data from Hacker News

Bazel – Correct, reproducible, fast builds for everyone

bazel.io

11–20 of 185 posts

Re: Bazel – Correct, reproducible, fast builds for everyone

#11
post #4

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's awesome to know that I can. I think this could be hugely useful to very large open source projects (like databases or operating systems) that may be intimidating for contri…

So the builds are reproducible automatically?

[deleted]

Re: Bazel – Correct, reproducible, fast builds for everyone

#12
post #6

Earlier quoted context omitted.

... that exploits parallelism and caching (and a hot VM) to accelerate build of huge projects, and supports build clusters.

huge Java projects...why would you compare a general build tool to a language-specific one?

What difference does that make? I am not saying you could replace this tool with sjavac, but as they both tout speed as their main feature (and justification), I am wondering whether they both employ the same techniques or different ones.

Re: Bazel – Correct, reproducible, fast builds for everyone

#13
post #9
post #3

How does it compare with Java 9's sjavac ( http://stackoverflow.com/a/26424760/750563 )? EDIT: I fully understand that this is a build tool for multiple languages. But its raison d'etre is speed. So I'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?

I work on Bazel. Bazel also builds other languages, such as C++ and Objective-C. We do invoke the Java compiler through a wrapper of our own. We think we can make that work as a daemon process to benefit from a hot JVM, but haven't gotten round to that.

Do you also use timestamps like sjavac or some other mechanism, like hashing?

Re: Bazel – Correct, reproducible, fast builds for everyone

#14
post #9
post #3

How does it compare with Java 9's sjavac ( http://stackoverflow.com/a/26424760/750563 )? EDIT: I fully understand that this is a build tool for multiple languages. But its raison d'etre is speed. So I'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?

I work on Bazel. Bazel also builds other languages, such as C++ and Objective-C. We do invoke the Java compiler through a wrapper of our own. We think we can make that work as a daemon process to benefit from a hot JVM, but haven't gotten round to that.

Any plans on supporting Windows? That will definitely increase the adoption of Bazel.

Re: Bazel – Correct, reproducible, fast builds for everyone

#15
post #4

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's awesome to know that I can. I think this could be hugely useful to very large open source projects (like databases or operating systems) that may be intimidating for contri…

Well, that's also largely due to all the source (transitive dependencies) being present in one monolithic repo.

Re: Bazel – Correct, reproducible, fast builds for everyone

#16
post #13
post #9

Earlier quoted context omitted.

I work on Bazel. Bazel also builds other languages, such as C++ and Objective-C. We do invoke the Java compiler through a wrapper of our own. We think we can make that work as a daemon process to benefit from a hot JVM, but haven't gotten round to that.

Do you also use timestamps like sjavac or some other mechanism, like hashing?

Bazel uses checksums to determine if builds are up-to-date, but shortcuts the checksumming if metadata (timestamp, filesize) have not changed between builds.

Re: Bazel – Correct, reproducible, fast builds for everyone

#18
post #9

Earlier quoted context omitted.

I work on Bazel. Bazel also builds other languages, such as C++ and Objective-C. We do invoke the Java compiler through a wrapper of our own. We think we can make that work as a daemon process to benefit from a hot JVM, but haven't gotten round to that.

Any plans on supporting Windows? That will definitely increase the adoption of Bazel.

http://bazel.io/docs/FAQ.html - "What about Windows?

We have experimented with a Windows port using MinGW/MSYS, but have no plans to invest in this port right now. Due to its Unix heritage, porting Bazel is significant work. For example, Bazel uses symlinks extensively, which has varying levels of support across Windows versions."

In other words: it's a lot of work, and frankly, our team doesn't know enough about windows to be very good at porting it. We would welcome contributions to make it work on Windows, of course.

Re: Bazel – Correct, reproducible, fast builds for everyone

#19
post #4

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's awesome to know that I can. I think this could be hugely useful to very large open source projects (like databases or operating systems) that may be intimidating for contri…

Yes, Blaze and a hojillion computers will give you a spiffy build system. The public now has the former, but not the latter :)

Re: Bazel – Correct, reproducible, fast builds for everyone

#20
post #6
post #5

Earlier quoted context omitted.

I don't think they're even related, Bazel is a general build tool, sjavac looks like a smarter Java compiler ?

... that exploits parallelism and caching (and a hot VM) to accelerate build of huge projects, and supports build clusters.

Inside Google we do that as well, but it's actually distinct from bazel. Bazel is a build language, and I believe they provide a reference implementation. It's not unimaginable (and as I mentioned, it has been done internally) to use caching, incremental, distributed builds. In fact, it was originally designed with those goals in mind.
Post reply on HN