Skip to content

Feature request: Use response files for rustc build/doc. #7759

Closed
@MaulingMonkey

Description

@MaulingMonkey

(EDIT: rustc response files are not yet stabilized, but it looks like they will be in 1.41?)

Describe the problem you are trying to solve

Some crates have hundreds upon hundreds - if not thousands - of features to manage compile times. If writing wildcard features that include a significant subset of these features, it's easy to exceed command line length limits on Windows:

error: could not compile `jni-android-sys`.

Caused by:
  could not execute process `rustc --edition=2018 --crate-name ...
  ...thousands of --cfg "feature=\"x-y-z\"" flags...
  ... (never executed)

Caused by:
  The filename or extension is too long. (os error 206)

As an awkward workaround, you can have a feature simply not specify the features it depends on, and instead do them all in code. E.g. instead of:

#[cfg(feature = "java-lang-Object")]

I've been generating:

#[cfg(any(feature = "all", feature = "java", feature = "java-lang", feature = "java-lang-Object"))]

But this has to be done every time you want to check the existence of java::lang::Object, and this isn't even the worst version.

Describe the solution you'd like

rustc already supports @path arguments / response files... so we could just leverage those. The main annoyances are refactoring and figuring out what commands need to use response files ("all rustc invokes"?)

Notes

I'm taking a quick stab at seeing how easy this is to implement... by which I mean all the unit tests are failing and it's probably my fault...

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-feature-requestCategory: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions