Build with bazel?

[pcj]

Given that this project is a bazel build file generator, seems like it should build with bazel. Specifically, I'd like to pull down and reference a rust_binary without having to use crates.io / cargo itself!.

[acmcarther]

Similar issue from a while ago:
acmcarther/cargo-raze#14

Historical blocker has been that this crate transitively depends on SSL crates (via Cargo itself), which require manual tweaks. Some thought also would need to go into what the bootstrapping behavior should look like. I've punted on this because I'd like a more general/durable approach for patching generated BUILD files.

I'm interested and historically have been interested in a feature like this because it enables using cargo-raze within a genrule or repository rule, which might be interesting.

EDIT:

That said, if anyone would immediately derive value from having this be buildable as a remote repository without a generation step, then that could be done as a one-off thing by committing a WORKSPACE file and some BUILD files. It might require some hacks in order to be multi-platform, but I think its doable.

[mfarrugi]

@pcj is vendoring (a release of) the binary sufficient?

Is your goal for a user to be able to build a repository with just an installation of bazel, or something else?

[pcj]

Well, I think what I'd like to do is use cargo-raze in a similar manner to bazel-gazelle. In that scenario, a user declares a dependency on io_bazel_rules_go, a dependency on bazel_gazelle, and then has a gazelle() rule in a BUILD file that, when run, modifies the BUILD files in the workspace. It has to do a realpath trick to break out of the sandbox and figure out the actual workspace directory.

Analogously, if I had an existing dependency on io_bazel_rules_rust and cargo_raze, I could probably build a cargo_raze() rule that I could invoke as bazel run //:cargo-raze and have it (a) build the cargo-raze tool from source (if needed), and then (b) use that tool to update the dependencies in a Cargo.toml file.

Granted, I suppose the ergonomics aren't that different from the existing workflow, but anyway that's what I'm thinking. And it spares me from having to have rust and cargo already on my system.

[qzmfranklin]

Agree with @pcj on making cargo-raze be similar to bazel-gazelle in terms of bootstrapping. That is more general.

Looks like this issue has been stale for a while. Is there any initiative from within Google that does this?

[acmcarther]

There isn't any existing effort to make this happen. This project is a 20% effort (largely less than that recently), and community input and contributions are very welcome.

The notes from a meeting of large companies using rust (direct link to notes here) are probably the clearest picture I can give as to what is happening in-organization.

[GregBowyer]

@qzmfranklin The big blocker here (I tried and gave up somewhat) is what to do about cargo itself.

Currently cargo-raze defaults to cargos api for getting details about packages, as such to get this working means getting cargo to compile in bazel by itself thats not too hard, but it also means curl-sys (and curl) openssl-sys (and thus openssl) and some other deps.

Naturally I, you and others probably have these in our respective trees, but with subtly different configurations and names. I personally am not a fan of bazel aliases for deps and for rules and tools to bring deps into our tree that we cant easily control.

The other option would thus to be use cargo as a tool inside bazel, maybe having rules_rust expose it as yet another tool to be downloaded and used. This would possibly be better although suffers from being potentially a tad unhermetic and needing some rules_rust work.

Right now I come away from this and figure that presently its better as a bridge program between the two worlds that places its feet more in the rust / cargo kingdom than the bazel one.

[dfreese]

@GregBowyer perhaps things are a little easier now that #156 has been merged?

[UebelAndre]

This seems possible but I don't think would be a good idea to tackle right now. I feel like there's some "chicken and egg" issues building with Bazel would introduce. However, that said, smoke-test.sh could easily be a run target that generates the examples and that directory would get added to .bazelignore and the rest of the actual testing functionality in there would become test targets.

[UebelAndre]

Cargo raze is totally buildable with Bazel as of #340 If anyone finds something not working about the Bazel builds, they should open a new ticket but I think this ticket could be closed.

[dfreese]

Closing as this has been implemented. CI, due to forcibly migrating from Travis, doesn't test this functionality currently.

Github actions look promising (example PR), but I hit some roadblocks with examples that I didn't understand and haven't had to investigate further.

[UebelAndre]

FWIW I have this nearly completely building in bazelbuild/rules_rust#578

The two notable parts:

1. I disabled examples on windows. This is something that's never been tested before and shouldn't block getting CI setup
2. MacOS is currently broken because CMake is no longer included in the base test runner and CMake is required by targets built using rules_foreign_cc. A fix is being worked on in Add repository rules for fetching prebuilt build tools (cmake, ninja, etc...) bazelbuild/rules_foreign_cc#497

To get this working, I've made a few changes that I've opened in PRs (and some I'm waiting on other PRs to go through). It'd help a lot to get those through