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

Bazel 1.0

opensource.googleblog.com

Post reply on HN
Print view View original

31–40 of 204 posts

Re: Bazel 1.0

#31

Post by paulddraper »

taneq wrote: post #6

Problem: There are N confusing build systems with arcane rules and you just want to compile your program. Solution: Design a simple, straightforward build tool. Problem: There are N+1 confusing build systems with arcane rules.

That's not really the problem Bazel is trying to solve.

Yes, a big design requirement is to be polyglot, but if that's all you want, Make has been around thirty years.

Bazel attempts to solve the problem of performance and correctness in large codebases.

Most build tools do not scale well.

Re: Bazel 1.0

#32

Post by trimbo »

taneq wrote: post #6

Problem: There are N confusing build systems with arcane rules and you just want to compile your program. Solution: Design a simple, straightforward build tool. Problem: There are N+1 confusing build systems with arcane rules.

Except half of the N were Xooglers implementing their own clone of Blaze.

Re: Bazel 1.0

#33

Post by ksec »

RcouF1uZ4gsC wrote: post #8

I only wish Bazel had been written in a language that produced native binaries like C++ or Go instead of Java. It seems like a waste for me as a non-Java developer to install Java on my dev machine just for Bazel.

>I only wish Bazel had been written in a language that produced native binaries like C++ or Go instead of Java.

Java can be compiled into native binaries using GraalVM. Not to mention you dont actually have to install Java as it comes in bundled.

Re: Bazel 1.0

#34

Post by weberc2 »

RhodesianHunter wrote: post #12
RcouF1uZ4gsC wrote: post #8

I only wish Bazel had been written in a language that produced native binaries like C++ or Go instead of Java. It seems like a waste for me as a non-Java developer to install Java on my dev machine just for Bazel.

Why do you care if a JVM is on your dev machine?

My 2015 MBP is crawling between Safari, Docker, VS Code, and BitDefender (antivirus). Not sure how bulky the JVM is these days. That said, I wish it supported Python.

Re: Bazel 1.0

#35

Post by paulddraper »

bradfitz wrote: post #25
paulddraper wrote: post #19

Earlier quoted context omitted.

Parts of Bazel are written in C/C++. The command line client as well as some low level file utilities. But Bazel is distributed as a standalone package in several packaging systems; no need to install Java yourself. Though I doubt many people know this; there's virtually no reason you would be exposed to its language implementation choices. EDIT: Actually I believe Bazel is changing its .deb package to not be standal…

> there's virtually no reason you would be exposed to its language implementation choices Um, doesn't it still have a client that starts up a persistent server and you then have to wait for that server to start up (which, being Java, takes forever) and then deal with those server processes hanging around? That sounds like being exposed to its language implementation choices. As opposed to, say, having fast start-up t…

Bazel doesn't start a server for Java JIT reasons.

It starts a server for (1) concurrency control (2) management of worker processes some languages use (3) caching the build graph (recall that Bazel works with very large code bases).

These reasons are independent of implementation in C++, Go, Rust, Java AOT, etc.

(And yes it doesn't have to use a persistent process to solve these problems. That is the solution it chooses.)

> not using a server design like basically every other build too

Buck, Pants, sbt, Gradle

Re: Bazel 1.0

#36

Post by 1propionyl »

srgpqt wrote: post #22
mrath wrote: post #13

Earlier quoted context omitted.

For me the obstacle for using make is, it is not available for windows and even if I install via msys2 or cygwin, it is hard it make Makefiles independent of OS. I am not sure Bazel is the answer. BUILD files feel verbose and need more effort to maintain than platform specific files(go.mod, Cargo.toml, pom.xml).

Visual Studio (used to?) come with nmake, a mostly compatible version of Make.

used to come with mostly compatible version of .

Yup.

Re: Bazel 1.0

#37

Post by flukus »

mrath wrote: post #13
1propionyl wrote: post #2

Because I have a twisted fascination with controversy and tribalism on HN, here's a little red meat: I'm going to stick with using make to glue together whatever tools I need for my build and test processes. Edit: -5 in under 10m. And yet I didn't even say anything remotely controversial or normative. Fantastic.

For me the obstacle for using make is, it is not available for windows and even if I install via msys2 or cygwin, it is hard it make Makefiles independent of OS. I am not sure Bazel is the answer. BUILD files feel verbose and need more effort to maintain than platform specific files(go.mod, Cargo.toml, pom.xml).

As long as you've got a basic unix like environment what's hard about being cross platform? Last time I tried it was very simple, at least with higher level languages and using gnu make specific features.

For build tools I think "defining their own platform" tends to be a better description than being cross platform, the have there own languages, tools and idioms. In this case it's on top of the java platform as well.

Re: Bazel 1.0

#38

Post by klodolph »

taneq wrote: post #28
klodolph wrote: post #10

Earlier quoted context omitted.

I’m getting a little tired of this particular brand of lazy cynicism. I’m happy to see people inventing new build systems, programming languages, game engines, ORMs, or anything else where the conventional wisdom is to use the existing tools. It may be crazy optimistic but we need people to keep these skill sets alive.

Sure, but don't ignore the fact that new things are technical debt. Maybe they're worth it, but they're still debt.

I don’t think that you and I have the same idea of what “technical debt” is.

Technical debt is when you prioritize short-term gains and pay for it with additional maintenance burdens long-term. In my experience, Bazel adoption can be the opposite—replace your custom scripts with Bazel, make the investment now, and deal with less maintenance later.

I’ve dealt with some really painful in-house build systems, and migrated some of them to Bazel. That was paying off technical debt.

Re: Bazel 1.0

#39

Post by klodolph »

taeric wrote: post #24
klodolph wrote: post #10

Earlier quoted context omitted.

I’m getting a little tired of this particular brand of lazy cynicism. I’m happy to see people inventing new build systems, programming languages, game engines, ORMs, or anything else where the conventional wisdom is to use the existing tools. It may be crazy optimistic but we need people to keep these skill sets alive.

I agree at a personal level. If anyone is pushing a toy project, basically no reason to knock it. Reason that Serenity OS story a few days ago was awesome. However, solutions pushed by corporations with grandiose claims do strike a nerve with me. If only because they are typically pushed with the idea that they will spread through some technical superiority. I'm much more open to this getting more use strictly from w…

It is successful enough that it has spawned a few clones—Buck, Pants, Please.build, and the thing that Chromium uses now. From what I can tell, before Bazel was open-source, everyone who left Google wanted to use Blaze badly enough to write their own version.

Re: Bazel 1.0

#40

Post by joshuamorton »

mook wrote: post #30
new_realist wrote: post #7

Earlier quoted context omitted.

I wouldn’t call Bazel confusing or arcane, but it is powerful. I find it rather delightful to use.

As a relatively newcomer to bazel, I did find it arcane: - I couldn't find an easy way to list targets - in particular, a way to show me the path to the build artifacts (so that I could inspect it in my editor) - I couldn't find a way to do build configurations (especially intersections of build configurations) - it didn't seem great at handling non-file build steps (set up a cluster / server / whatever so I can run…

Configs: look into select() and modes.

Non-file steps: normally in bazel you would consider the server setup a part of the test. So `blaze build :my_test` creates an artifact, and blaze run or blaze test runs the artifact which does non-hermetic stuff like setting up a server.

Post reply on HN