Export more build metadata from `cargo build`

[jsgf]

In order to integrate the build products from cargo build in other build systems, for each crate it would be useful to know:

• the pathname of the build product (the .rlib file, including the magic metadata string)
• the metadata/extra_filename separately
• dependency on other crates (which can probably be computed from other existing metadata, but doing so would require re-implementing what cargo is doing anyway, esp with feature-dependent dependencies)
• dependencies on native libraries
• perhaps other details from build scripts

This could fit into the #3000 infrastructure, but my purposes streaming output isn't really necessary (ie, a single blob of json at the end of successful compilation would be as good). But streaming should definitely be workable.

PR #3111 was an attempt at doing this, but it doesn't look like it's practical to do it independently from the actual build, esp because of things like #3102.

[retep998]

dependencies on native libraries

When creating a staticlib rustc prints out which native libraries you have to link to, so having that as part of the metadata is a good idea. Figuring out which DLLs your thing will have a runtime dependence on however is silly hard on Windows, and it would be better to simply analyze the final binary yourself to figure that out.

[jsgf]

Figuring out which DLLs your thing will have a runtime dependence on however is silly hard on Windows

Do .rlib files have some kind of reference to the .dll files they depend on, even if it's a logical name rather than resolved to a specific path?

[retep998]

@jsgf No. .rlib files don't depend on .dlls to begin with. They merely have a set of unresolved symbols, and the names of .libs that will be passed to the linker to hopefully resolve those symbols. There's no way to know whether a symbol actually resolved to an import from a .dll until you actually link everything, at which point you can use a variety of tools to just look at the import table for the binary to see what .dlls it depends on.

[jsgf]

I don't know about windows, but in Linux/Unix/(MacOS?) builds, the .rlib contains references to any native libraries it has dependencies on, so that at final link time, rustc knows what libraries it needs to find and link in (they're not explicitly listed on the command line, as they would be for a C/C++ build).

[retep998]

@jsgf It's the same for Windows. It's just that on Windows you always link to a .lib (or .a for mingw) and can sometimes end up with a runtime dependency on a .dll (you never link to a .dll directly), while on other platforms you only gain a runtime dependency on a .so when you explicitly link to that .so.