Can I inject a non-cargo dependency into `cargo rustc`?

(I haven't tried it yet, but probably will within a week.)

Assuming I have the rlib result of cargo building some library, is it possible to provide that to a later cargo invocation (with a distinct target directory) and avoid building the original library again?

Or IOW, is providing --extern libMyUpstreamLib.rlib enough to add a dependency to a (cargo) rustc invocation, or do I also have to provide -L dependency=... to the injected library's build/deps folder?

The easy way would be just to share $CARGO_TARGET_DIR. Unfortunately, I'm working with integrating Cargo (or maybe eventually just rustc) into an existing C++ build system, and I'm trying to match the existing conventions as closely as possible, so that means separate intermediate directories.

The ultimate goal here is to allow Rust-implemented dependencies to be managed in the existing build system (that assumes a C++ model of include-path and then link), then used by downstream modules via the Rust API, not the C++ one, (If only because I want to have one canonical bridge between any given C++ module and Rust, rather than each downstream module reimplementing the FFI.) Plus, ideally, I want to do so while still keeping the crates ecosystem available, without just vendoring everything into tree. (That might end up what I end up doing, though... the existing third-party C++ code is vendored in (as binaries) of course.) I control the version of cargo/rustc used, so at the very least ABI instability isn't a concern, just plumbing.

Using patch-in-config gets me most of the way there, as I can inject a patch clause to set a dependency to a local crate to the correct local filesystem path. This requires double-building the library crate, though, so I'm not super enthused about it, on its own.

And yes, there's of course the issue both of breaking IDE intelligence by working around Cargo, and of mismatched dependency versions since there isn't a shared lockfile... I'm working on it, slowly.

This is more of a ramble than a useful question, but it has helped me realize that I'm probably best off just bypassing cargo and using rustc directly, a la Android's Soong build system, to get the control I want.

I guess you are asking “can cargo use binary dependencies?”, and I think the answer is no. I don’t know of anyone who tries to do this. Most of the time, folks write some tools to process Cargo.tomls and to output build files for the external build system.

As for IDE Intelligence, rust-analyzer support rust-project.json format. I think IntelliJ also wants to do this at some point, so opening an issue might help.