Yeah, my proposal is essentially to re-use the dependencies of the build context crate as the harness dependencies. It does mean that you end up pulling in slightly too many (larlpop_util in @fitzgen's example) when compiling the build context, but meh. That said, I'm also fine with a dedicated new section as in the current eRFC and @fitzgen's post above.
Ah, missed this. Yeah, I guess the build context crate has to include that as a field then. Either in Cargo.toml (which means either all the build contexts in a crate has it, or none do), or in the build_context annotation directly.
I still don't see how this presents any problem?
Seems fine.