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

Scaling Rust Builds with Bazel

mmapped.blog

Post reply on HN
Print view View original

21–30 of 133 posts

Re: Scaling Rust Builds with Bazel

#21

Post by rtpg »

illiarian wrote: post #19
rtpg wrote: post #16

Earlier quoted context omitted.

You have to declare in Bazel as well. But really, I think that people don't go extremely granular on this. For Rust projects that are spread over 10-100 crates, I think that most people would just model the crate dependencies rather than at a file level. Mostly for pragmatic reasons, but also because that will likely model your test suite closely and your build requirements. Bazel is a build tool, so one "module" (in…

> You have to declare in Bazel as well. > For Rust projects that are spread over 10-100 crates It's already 10-100 crates you need to manually declare and keep track of, or use a yet another tool to generate this for you. And for big projects you'd also want to go more granular and split by parts of your app I guess.

I mean in the "real world" what happens is you do this once, and then you keep on using it and gradually make changes. Annoying, of course, but I think cargo is fortunately still relatively simple stuff, so the scope is much smaller than, say, Python setup.py shenanigans (though Rust build.rs stuff will definitely require some futzing around with environment variables at the Cargo level).

The "obvious" thing would be to either generate cargo files from Bazel stuff, generate Bazel stuff from cargo files, or have a third source that generates both. And like... yeah, if you are suffering from compile time issues, Bazel can make that stuff order of magnitudes faster (especially if your dep tree is pretty horizontal), so there's a reason to do it!

Re: Scaling Rust Builds with Bazel

#22

Post by bjackman »

habitue wrote: post #12

Hey, what a surprise, ex-google engineers dragging everyone into bazel... Maybe you have some really complicated use case that makes cargo insufficient, but really, it's pretty damn nice and it's integrated with everything. There are languages that need bazel, rust isn't one of them

Lol, Googler here, I can't deny that I have he urge to force Bazel into the world.

It's just, when I joined Google I found a build system I didn't hate. This was the first time. I don't actually love Bazel (Blaze internally), but I love that I don't hate it.

Every time I have to learn a new build system in open source work I groan. Why are there so many systems for essentially the same thing?

Re: Scaling Rust Builds with Bazel

#23

Post by carlmr »

bjackman wrote: post #22
habitue wrote: post #12

Hey, what a surprise, ex-google engineers dragging everyone into bazel... Maybe you have some really complicated use case that makes cargo insufficient, but really, it's pretty damn nice and it's integrated with everything. There are languages that need bazel, rust isn't one of them

Lol, Googler here, I can't deny that I have he urge to force Bazel into the world. It's just, when I joined Google I found a build system I didn't hate. This was the first time. I don't actually love Bazel (Blaze internally), but I love that I don't hate it. Every time I have to learn a new build system in open source work I groan. Why are there so many systems for essentially the same thing?

Question for an insider. Bazel code coverage seems to be one of the roughest edges. At least when running C++ tests.

Only lcov is supported, and due to the sandboxing it's impossible to get other tools working since they always spit out extra instrumentation data that's neither cached nor available on the next sandbox.

Does blaze support code coverage properly? Does Google just not care about code coverage? Am I just missing some obvious thing in the documentation?

Re: Scaling Rust Builds with Bazel

#24

Post by carlmr »

habitue wrote: post #12

Hey, what a surprise, ex-google engineers dragging everyone into bazel... Maybe you have some really complicated use case that makes cargo insufficient, but really, it's pretty damn nice and it's integrated with everything. There are languages that need bazel, rust isn't one of them

I mean for C++ having the caching just work like you get with Bazel is a huge thing.

I agree that Cargo is already near perfect and I wouldn't suggest you switch to Bazel if you have a Rust project.

In our case we have a C++ project with some Python, some Rust. Having everything in Bazel here is good for us.

Re: Scaling Rust Builds with Bazel

#25

Post by charcircuit »

bilekas wrote: post #20
habitue wrote: post #12

Hey, what a surprise, ex-google engineers dragging everyone into bazel... Maybe you have some really complicated use case that makes cargo insufficient, but really, it's pretty damn nice and it's integrated with everything. There are languages that need bazel, rust isn't one of them

I'm inclined to agree, but mainly because I can't see an issue where cargo is insufficient, it seems to me that would be an issue somewhere else. Not cargo specific.

One category where it helps are *-sys packages which are lacking a proper build system. Cargo's build.rs is a messy solution and is pretty limited.

Re: Scaling Rust Builds with Bazel

#27

Post by wrigby »

illiarian wrote: post #18
keddad wrote: post #9

Earlier quoted context omitted.

You basically have to declare all those dependencies in Bazel. For instance, if you look at rules for Go, they declare the whole dependency graph (Modules, their relations) in Bazel. There is tooling to generate that for you, so it's not really that bad. Where it gets harder is when this language feature is integrated with an existing build system. C# is normally build with it's own build system, and to build it with…

> There is tooling to generate that for you, so it's not really that bad. So you need several layers of tooling just to get something built. It's bad

I may be missing something, but it’s quite similar to pkgconfig+(cmake|autoconf). If you include a header, your build system probably needs to know where on the filesystem that header exists.

Re: Scaling Rust Builds with Bazel

#29

Post by yosefk »

habitue wrote: post #12

Hey, what a surprise, ex-google engineers dragging everyone into bazel... Maybe you have some really complicated use case that makes cargo insufficient, but really, it's pretty damn nice and it's integrated with everything. There are languages that need bazel, rust isn't one of them

I never worked for Google nor worked with anyone from Google who said something like "you should move to Bazel" even once. I also did lots of work on in house build system migrations and optimizations.

Do you think that the problems with cargo mentioned in TFA are exaggerated or solvable? I think Bazel's support for caching, parallelism and custom rules are real advantages for large projects. What's wrong with this argument wrt Rust/cargo?

Re: Scaling Rust Builds with Bazel

#30

Post by ajconway »

bilekas wrote: post #20
habitue wrote: post #12

Hey, what a surprise, ex-google engineers dragging everyone into bazel... Maybe you have some really complicated use case that makes cargo insufficient, but really, it's pretty damn nice and it's integrated with everything. There are languages that need bazel, rust isn't one of them

I'm inclined to agree, but mainly because I can't see an issue where cargo is insufficient, it seems to me that would be an issue somewhere else. Not cargo specific.

Cargo is insufficient if a project has cross-language dependencies.
Post reply on HN