Skip to content

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

Closed

Description

@bjorn3

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.

Activity

  1. changed the title [-]Add an option put the metadata in a separate file[/-] [+][idea] Add an option put the metadata in a separate file[/+] on Dec 23, 2018
  2. Xanewok commented on Dec 28, 2018

    @Xanewok
    Contributor

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

  3. bjorn3 commented on Dec 28, 2018

    @bjorn3
    MemberAuthor

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

  4. bjorn3 commented on Dec 28, 2018

    @bjorn3
    MemberAuthor

    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.

  5. steveklabnik commented on Nov 13, 2019

    @steveklabnik
    Contributor

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

  6. added
    C-feature-requestCategory: A feature request, i.e: not implemented / a PR.
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Dec 8, 2019
  7. added a commit that references this issue on Feb 9, 2024
  8. added a commit that references this issue on Apr 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-metadataArea: Crate metadataC-feature-requestCategory: A feature request, i.e: not implemented / a PR.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions