Inconsistent cargo bazel lockfile between MacOS and Linux

[jvliwanag]

Given a rust project with the dependency: pbjson_types, the generated cargo bazel lockfile differs when generated on Mac and Linux.

See sample project here. The diff switching from the mac generated one to the linux one is on this commit.

Mac build is from an M2 Sonoma. Linux build is from a docker ubuntu arm64 image.

[gferon]

I encountered the exact same issue in the past few weeks. It is related to a (current) hard limitation of cargo metadata which does not expose features per target platform. Because of that, rules_rust relies on cargo tree to determine which features are enabled for each platform.

The problem with this approach is that cargo tree will always compute build dependencies for the host platform, which in your case can either be macOS or Linux.

One quick & dirty solution could be to add a --host-triple to cargo tree to be able to list build-dependencies for each platform Bazel is going to build on and for. I started a discussion with the cargo maintainers which pointed me towards cargo metadata.

It looks like we could improve cargo_universe a lot if cargo metadata would be able to use resolver = 2 but this sounds complicated, see: https://rust-lang.github.io/rfcs/2957-cargo-features2.html#cargo-metadata

This whole story was already discovered by @illicitonion a while ago in https://github.com/bazelbuild/rules_rust/issues/1662 - could you maybe give your two cents to help move in one direction or another?

Some extra relevant links:

• https://github.com/rust-lang/cargo/issues/9863
• https://github.com/rust-lang/rust-analyzer/issues/15233

[jvliwanag]

Thanks for looking into this. As this seems blocked though by changes we’d need on cargo, what would be viable options to workaround this issue for the meantime?

[illicitonion]

One quick & dirty solution could be to add a --host-triple to cargo tree to be able to list build-dependencies for each platform Bazel is going to build on and for.

This sounds like the right approach (until cargo metadata itself gets fixed) - we already have a list of the platforms we care about, and we're already serializing this as a SelectList, so running those cargo-trees and adding each resolved feature for each platform sounds reasonable.

[jvliwanag]

I’ve gotten around the issue for now by running cargo sync on the different platforms and adding them manually via annotations.

As such, looks like whatever would automate this would work for my case.

[gferon]

One quick & dirty solution could be to add a --host-triple to cargo tree to be able to list build-dependencies for each platform Bazel is going to build on and for.

This sounds like the right approach (until cargo metadata itself gets fixed) - we already have a list of the platforms we care about, and we're already serializing this as a SelectList, so running those cargo-trees and adding each resolved feature for each platform sounds reasonable.

I touched base with some cargo maintainers and didn't get very far with either solution. I'll keep thinking about how to proceed further.