3 ms·
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
by rtpg 4y ago
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 Bazel you talk about target) per build artifact basically aligns with what people want. But you can in theory go really granular, making it so that tests only run if files it depend on change (less granular and that becomes "crates they depend on change")
- illiarian 4y ago> 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.
- rtpg 4y agoI 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!