Proposal: allow crates to depend on a binary crate

[jcranmer]

Since I see this has been proposed a few times, but closed due to finding other solutions, let me explain a use case where I want this feature.

I have one crate (named asm-executor) that implements an execution oracle for assembly programs--you pass in an assembly-language program and a list of x86 machine states, and it outputs the results of running that assembly language on those x86 machine states (by running it on the CPU directly, no emulation). Since it's designed to handle memory accesses, I'd much rather execute the program in a separate address space to minimize "forbidden" address maps, and the easiest way of doing this is a binary.

This means I need some way of being able to say that I can depend on the crate in such a way that I can execute the binary contained within.

[Twey]

‘Me too.’ I have a test harness crate that involves, as part of its setup, running some binaries, then running some code that talks to them. These binaries are generated by cargo from within the same workspace. As it stands, I can't just run cargo test on the crate under interrogation, because the binaries used by the test harness may not have been updated: instead, I must write cargo build; cargo test because cargo doesn't know about these dependencies. Forgetting this sometimes results in confusing test failures.

[joshtriplett]

I'd love to have this as well.

Ideally, it would support a mechanism similar to the metadata that FFI crates provide, where it's possible for the depending crate's build script to get the path to the binary for the dependency.

[ehuss]

I think this issue should be covered by RFC 3028, so closing in favor of the tracking issue #9096.