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

Support generating interface files separately (and before) compiled code #39541

Closed
DemiMarie opened this issue Feb 4, 2017 · 7 comments
Closed
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. I-compiletime Issue: Problems and improvements with respect to compile times.

Comments

@DemiMarie
Copy link
Contributor

Rustc generates files containing both interface information (needed to compile other crates) and compiled object code (needed for linking only). Currently, any multi-crate build cannot start compiling other crates until both are available, since they are combined into one file.

However, there is no fundamental need for other crates to wait on the compiled object code. They really only need to wait on the interface information. This issue covers making the interface information available sooner, and providing a way to notify another process (perhaps by writing to a file descriptor/handle) when it is available.

@KalitaAlexey
Copy link
Contributor

@DemiMarie,
Why?
Compilation uses as much resources as possible.
There will be no win with the feature.

@est31
Copy link
Member

est31 commented Feb 4, 2017

I think I've suggested something like this before: https://internals.rust-lang.org/t/pre-rfc-generate-headers-for-greater-parallelism/4523

@Ixrec
Copy link
Contributor

Ixrec commented Feb 4, 2017

As mentioned on that thread, the potential benefits of this idea will probably fall out of #38913 and incremental compilation or at least have to wait until both of those make more progress.

@Mark-Simulacrum Mark-Simulacrum added the I-compiletime Issue: Problems and improvements with respect to compile times. label May 20, 2017
@Ericson2314
Copy link
Contributor

This is good for doing a "proof by construction" public-in-private check.

@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 27, 2017
@steveklabnik
Copy link
Member

Triage: there's been some work on some stuff like this recently, I think?

@est31
Copy link
Member

est31 commented Dec 20, 2019

@steveklabnik Yeah I'd say this issue is resolved in favour of #60988

@steveklabnik
Copy link
Member

Ah yes, that's the issue, thank you for finding it!

If anyone objects, please let me know, but I believe this is a duplicate of that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. I-compiletime Issue: Problems and improvements with respect to compile times.
Projects
None yet
Development

No branches or pull requests

7 participants