Open UebelAndre opened 3 years ago
My expectation is that by implementing this, the need for workspace_member_dependents
and workspace_member_dev_dependents
will be removed.
https://github.com/google/cargo-raze/blob/3b0a7cbc7ecc048c41ab6644f6108de650e3d1e7/impl/src/planning/subplanners.rs#L389-L390
These fields are used for the experimental API to render the dependency maps into crates.bzl
. If a PlannedBuild
can be made aware of the workspace members, then we can iterrate over those when rendering instead of iterating over each crate to find out if it's a dependency of the current package.
https://github.com/google/cargo-raze/blob/3b0a7cbc7ecc048c41ab6644f6108de650e3d1e7/impl/src/rendering/templates/partials/crates_macro.template#L3-L17
@GregBowyer Just wanted to share https://github.com/google/cargo-raze/issues/339#issuecomment-760405817 with you in case you find the existence of workspace_member_dependents
and workspace_member_dev_dependents
odd in CrateContext
.
https://github.com/google/cargo-raze/blob/3b0a7cbc7ecc048c41ab6644f6108de650e3d1e7/impl/src/context.rs#L128-L129
I'd like a
--init
argument (name WIP) that I can pass tocargo-raze
and have it not just output build files, but generate a Bazel workspace in place on top of a Cargo workspace with all the appropriate dependencies plugged in. This would help tremendously with migrating various repos over to using Bazel.It's worth noting that most, if not all, repositories are for binaries and will not be used for sharing dependencies. They're expected to be built, more or less, in isolation and used as tools for other rules or data for other targets. But even then, I would find it incredibly useful and in alignment with other Rust tools to have some kind of
--init
flag (cargo init, wasm-pack new).