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

[idea] Add an option put the metadata in a separate file #57076

Open
bjorn3 opened this issue Dec 23, 2018 · 4 comments · May be fixed by #120855
Open

[idea] Add an option put the metadata in a separate file #57076

bjorn3 opened this issue Dec 23, 2018 · 4 comments · May be fixed by #120855
Labels
A-metadata Area: Crate metadata C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@bjorn3
Copy link
Member

bjorn3 commented Dec 23, 2018

Detailed design

When -Zsplit-metadata is passed to rustc, it will put the metadata normally inside a rlib or dylib in a separate rmeta file. The rlib/dylib will contain the SVH to prevent accidentally mixing the rmeta and rlib/dylib of different compilations.

Advantages

This would make the increase in size of #56987 easily fixable by deleting the rlib files, while keeping the rmeta files. Those are not necessary anyway, because rustc_driver.so already contains the code.

This will decrease staticlib, dylib and cdylib compilation time, because there is no need to copy all object files to a new archive to remove the rust.metadata.bin file from the rlib.

if f.ends_with(RLIB_BYTECODE_EXTENSION) || f == METADATA_FILENAME {
archive.remove_file(&f);
continue

Disadvantages

Rustc and cargo get a bit more complex.

@bjorn3 bjorn3 changed the title Add an option put the metadata in a separate file [idea] Add an option put the metadata in a separate file Dec 23, 2018
@Centril Centril added the A-metadata Area: Crate metadata label Dec 28, 2018
@Xanewok
Copy link
Member

Xanewok commented Dec 28, 2018

If I understand this correctly, an another advantage is that we'd get a cargo check done for free when we do cargo {build, run, test}, which might speed up some workflows (no need to generate separate .rmeta for deps).

@bjorn3
Copy link
Member Author

bjorn3 commented Dec 28, 2018

@Xanewok If I read rust-lang/cargo#3501 correctly, it is technically possible to do so already, but cargo doesn't support it.

@bjorn3
Copy link
Member Author

bjorn3 commented Dec 28, 2018

If this is accepted rust-lang/cargo#4831 could be done without invoking rustc twice. Just let rustc print a message when the metadata file is emitted and allow it to read .rmeta files before the .rlib file is ready. When a crate is built which needs to run the linker (dylib or bin) either cargo or rustc could wait till all necessary .rlib files are generated.

@steveklabnik
Copy link
Member

Triage: no real changes; sort of a duplicate of the cargo ticket, kinda.

@jonas-schievink jonas-schievink added C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 8, 2019
@bjorn3 bjorn3 linked a pull request Feb 9, 2024 that will close this issue
bors added a commit to rust-lang-ci/rust that referenced this issue Feb 9, 2024
Introduce -Zsplit-metadata option

This will split the crate metadata out of library files. Instead only the svh and a bit of extra metadata is preserved to allow for loading the right rmeta file. This significantly reduces library size. In addition it allows for cheaper checks if different library files are the same crate.

A fair amount of the complexity in this PR is to work around the fact that cargo doesn't directly support this option yet.

Fixes rust-lang#23366
Fixes rust-lang#57076

Revives rust-lang#93945
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-metadata Area: Crate metadata C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants