optional deps - should I file a bug or is this expected?

[rbtcollins]

I have a crate that I would like to have dual-build enabled to facilitate migrations internally.

It has a feature:

foo = [
"dep:bar"
]
....
[build-dependencies]
bar = {version="1", optional=True}

and a build.rs that uses the dep.

cargo_build_script(
    name = "build_script",
    srcs = glob(["build/**"]),
    crate_features = [
        "foo",
    ],
    proc_macro_deps = all_crate_deps(build_proc_macro = True),
    deps = all_crate_deps(build = True),
)

When I pass crate_features=["foo"] to the cargo_build_script rule, it correctly enables the code, but fails to compile due to missing dependencies

...
^^^^^^^^^^^ use of undeclared crate or module `bar`

If I remove the dep:bar from the feature and mark the dependency as non-optional, it compiles, but this breaks non-bazel use.

Am I doing it wrong or is this a bug?

[UebelAndre]

This is somewhat expected. Dependencies are generated from a snapshot of the current workspace and only as far as cargo can see it. Optional features which enable dependencies must be enabled when you generate dependencies or they'll be skipped. If you want this level of control you'll probably need to manage dependencies yourself instead of using the all_crate_deps macros.

[UebelAndre]

If you have thoughts on how to improve the experience though I'm always interested to hear 😄

[rbtcollins]

Let me think about this out loud for a second.

The dependency generating code scans the workspace and generates Cargo.lock, and then introspects each target Cargo knows about to retrieve the direct dependencies of that target.

There are then three interesting questions:

• choosing which of the 2^featurecount build configurations to produce
• which is a requirement for supporting appropriate feature unification
• and a requirement for emitting the bazel form of the dependencies

One possibility is to enable all features for the purpose of calculating dependencies; this doesn't help with feature unification, because a different bazel target is needed to represent feature unification, but it would permit builds to succeed: there would be an unneeded crate in the dep tree, but no code would use it.

Another possibility is to review all the rust targets that match that cargo target, and inspect selected cargo_features there, and use that to update Cargo's metadata and thus the enabled crates?