Exposing static lib dependencies

[kornel]

When building static libraries rustc currently prints required dependencies:

note: link against the following native artifacts when linking against this static library
note: library: System
note: library: resolv
note: library: c
note: library: m

I've recently made a PR to change the format it uses and display only when --print=native-static-libs flag is added, but I'm having doubts whether this was a good idea:

• printing of all other things is done instead of compilation, but this option is an exception that it prints while building
• it still prints as a "note:", requiring parsing of rustc output.
• This overlaps with RFC for build system integration eRFC: Cargo build system integration by aturon · Pull Request #2136 · rust-lang/rfcs · GitHub and from integration perspective, it's not good.

Any suggestions what, if anything, should be done with it? I wonder whether releasing this flag now will create a feature that becomes obsolete by future build system integration, causing unnecessary churn.

I've changed the list of libraries to be printed in a more useful format, but in retrospect, printing is probably inappropriate method. I think these flags should be written to a file in the same location as the .a file produced (e.g. in libfoo.a.linkflags), so that users of the library can find the metadata after the build, and rustc regular text output is not abused as loosely structured data format for interchange.

[Michael-F-Bryan]

I just added a comment to your PR, but I definitely agree we should find a better solution for this. At the moment the notes will be unconditionally printed to the screen (even though it says it’s not on by default), adding a lot of unnecessary noise to the compiler output.

It’s probably better to make this part of the build system RFC. External build systems will need to know what native artefacts you need to link with anyway (otherwise the build will fail), so it’d be better to notify them using the appropriate mechanism.

[kornel]

I haven’t heard feedback about any alternatives from anyone using this method or the compiler team, so I’m going to assume nobody cares, and proceed with the original plan to keeping this printed, but as an opt-in.

If a need for another interface arises in the build system integration work that’s great. It needs to be driven by use-cases rather than guessing what may be needed.