Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Export more build metadata from cargo build #3212

Closed
jsgf opened this issue Oct 19, 2016 · 5 comments · Fixed by #3319
Closed

Export more build metadata from cargo build #3212

jsgf opened this issue Oct 19, 2016 · 5 comments · Fixed by #3319

Comments

@jsgf
Copy link
Contributor

jsgf commented Oct 19, 2016

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
Copy link
Member

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
Copy link
Contributor Author

jsgf commented Oct 19, 2016

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
Copy link
Member

retep998 commented Oct 19, 2016

@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
Copy link
Contributor Author

jsgf commented Oct 19, 2016

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
Copy link
Member

@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.

alexcrichton added a commit to alexcrichton/cargo that referenced this issue Dec 2, 2016
This adds more output on Cargo's behalf to the output of
`--message-format=json`. Cargo will now emit a message when a crate is finished
compiling with a list of all files that were just generated along with a message
when a build script finishes executing with linked libraries and linked library
paths.

Closes rust-lang#3212
bors added a commit that referenced this issue Dec 6, 2016
Emit more info on --message-format=json

This adds more output on Cargo's behalf to the output of
`--message-format=json`. Cargo will now emit a message when a crate is finished
compiling with a list of all files that were just generated along with a message
when a build script finishes executing with linked libraries and linked library
paths.

Closes #3212
@bors bors closed this as completed in #3319 Dec 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants