Live data from Hacker News

Bazel – Correct, reproducible, fast builds for everyone

bazel.io

81–90 of 185 posts

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

#81
post #28

What would be needed to get this to work with Haskell? I read in the "Getting started": > You can now create your own targets and compose them. So does this mean it is a replacement for `make`? => Yes Found the answer here: http://bazel.io/docs/FAQ.html

If you're interested in adding rules for a new language, check out Skylark: http://bazel.io/docs/skylark/concepts.html.

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

#82
post #75
post #62

Earlier quoted context omitted.

Do you have a link to that white paper? A quick search on their research site doesn't really yield any results.

I'm a developer on Bazel, and AFAIK there is no white paper. We definitely don't want to "throw it over the wall," we're going to try to push more and more development into the open over time.

Ah, OK, thanks. I do get a kick out of reading various Google white papers (GFS, Spanner, and the Multi-Paxos implementation for Chubby come to mind), so I'd definitely be interested in the prospect of a future white paper :).

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

#83
post #80
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…

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 evangelizing them.

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

#84
post #59

What 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 bu…

This is why you should have repository manager like JFrog Artifactory or Sonatype Nexus which can transparently proxy third-party repositories (like Maven Central).

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

#87
post #10

Earlier quoted context omitted.

So the builds are reproducible automatically?

See http://bazel.io/docs/FAQ.html , "Will Bazel make my builds reproducible automatically? For Java and C++ binaries, yes, assuming you do not change the toolchain. If you have build steps that involve custom recipes (eg. executing binaries through a shell script inside a rule), you will need to take some extra care: Do not use dependencies that were not declared. Sandboxed execution (–spawn_strategy=sandboxed, only…

When you say Java, does that include Android? I see that Android is supported, but couldn't find anything about reproducibility.

Reproducible Android builds would be very interesting.

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

#88
Maven doesn't work so well when there are loads of small self contained 'micro-libraries' (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.

Presumably will also make opensourcing internal projects easier. That can't be a bad thing :)

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

#89
post #17

Correct, reproducible, fast builds for everyone not running Windows

s/not running Windows/not running Windows or refusing to install a free VM/ 5 or 6 years ago I had to have Windows to run CAD software, but I found it easier to have a virtualbox install w/ Ubuntu in it for software development than trying to write code on Windows. The performance was good enough an the usability was pretty good. I imagine it has only gotten better since then.

One company I work with has a firewall of a certain brand. It only works with windows or a mac, you can't connect to it from a command line it needs some stupid app that you download and install just to make a VPN connection.

Not having a unix specific build system work on windows seems to be pretty much the expected behaviour. As opposed to a firewall that runs linux internally requiring windows or OS/X to talk to it...

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

#90
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'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).
Post reply on HN