Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bazel – Correct, reproducible, fast builds for everyone

bazel.io

Post reply on HN
Print view View original

101–110 of 185 posts

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

#101

Post by MrBuddyCasino »

hanwenn wrote: post #18
moondowner wrote: post #14

Earlier quoted context omitted.

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 win…

That would be great. I'm not a Windows user, but having Windows support is a pre-requisite for adoption in many corporate environments, and proper symlinks are available since Windows Vista.

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

#103

Post by [deleted] »

habosa wrote: 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…

[deleted]

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

#104

Post by OneMoreGoogler »

habosa wrote: 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…

> Any engineer can build any Google product from source on any machine

A little too optimistic :) You can't build Android, Chrome, ChromeOS, iOS apps, etc. via blaze.

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

#107

Post by oppositelock »

GauntletWizard wrote: post #83
emu wrote: post #80

Earlier quoted context omitted.

Standard caveat: I don't speak for my employer. Using Bazel (aka. Blaze) every day is one of the things that has made me dread ever leaving Google. Fast, reproducible builds are amazing . Once you have used this tool, it is very hard to go back. Personally, I'm thrilled that it has been open sourced.

Having recently left Google, GRPC (stubby) was my biggest concern; I spent about two weeks hacking together a good code generator for GoRPC before GRPC came out and obviated the time. Now, I'm glad I haven't bothered with a build system, which was going to be next. Nice to see a bunch of projects that've been generalizable and heavily used internally finally see the light of the outside world. Now, to start evangeliz…

A huge +1 on this as well.

I left Google a couple of years ago and we ended up building our own rpc around protos (Thrift just doesn't cut it), and our Make/maven based build has the standard problems with such things, so I'm really looking forward to using grpc and bazel in the near future. A huge thumbs up to Google!

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

#108

Post by ulfjack »

astral303 wrote: post #50
setheron wrote: post #36

If i'm sticking to primarily Java; is there a benefit to using Bazel as opposed to Maven / Gradle / Sbt ?

At first impression, unless you have a single gigantic source code base, unlikely. From their FAQ: >> "Gradle: Bazel configuration files are much more structured than Gradle's, letting Bazel understand exactly what each action does. This allows for more parallelism and better reproducibility" The value of "more parallelism" depends on the complexity of your Java source code base. I can easily imagine why this extra s…

I work on Bazel.

We've put a bunch of work into making sure that we know about every file that goes into the Java compilation, and if any of them changes (and only then) do we recompile. Within Google, we use a form of sandboxing to enforce that.

You're also right that it isn't free - we have reason to believe that larger projects and larger teams will see benefits from using Bazel. Use your best judgement.

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

#109

Post by ulfjack »

rquirk wrote: post #66
MichaelGG wrote: post #63

Earlier quoted context omitted.

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.

We realize that not everyone wants to check in all of their dependencies, and that's cool too. Check out the build encyclopedia for rules to talk to 'plain http' and maven repositories.

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

#110

Post by needusername »

kchod wrote: post #37
pacala wrote: post #23

A couple of questions: * If I have a Maven-based project with heavy reliance on pre-built jars from Maven Central, what's the recipe to port it to Bazel? * Related, if I have multiple github repos, say a couple open source libraries and a couple private repos, what's a good recipe in conjunction to Bazel?

Check out http://bazel.io/docs/build-encyclopedia.html#maven_jar . In the root of your build, specify the jars you want from maven and then add them as dependencies in your BUILD files. The first time you run "bazel build", they'll be downloaded and cached from then on. It's somewhat limited in functionality at the moment, but should work for basic "download and depend on a jar". For multiple Github repos, use http:/…

Regarding Maven: - how do you resolve artifacts (eg. are you using Aether)? - are you supporting classifier and type for dependencies?
Post reply on HN