-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Comments
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. |
Do |
@jsgf No. |
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, |
@jsgf It's the same for Windows. It's just that on Windows you always link to a |
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
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
In order to integrate the build products from
cargo build
in other build systems, for each crate it would be useful to know:.rlib
file, including the magic metadata string)extra_filename
separatelyThis 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.
The text was updated successfully, but these errors were encountered: