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

Changing profile.*.lto in Cargo.toml shouldn't rebuild everything #3244

Open
japaric opened this issue Nov 1, 2016 · 5 comments
Open

Changing profile.*.lto in Cargo.toml shouldn't rebuild everything #3244

japaric opened this issue Nov 1, 2016 · 5 comments
Labels
A-linkage Area: linker issues, dylib, cdylib, shared libraries, so A-lto Area: link-time optimization A-rebuild-detection Area: rebuild detection and fingerprinting C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-build S-needs-mentor Status: Issue or feature is accepted, but needs a team member to commit to helping and reviewing.

Comments

@japaric
Copy link
Member

japaric commented Nov 1, 2016

Neither should adding, modifying or removing linker flags via -C link-arg or -C link-args in .cargo/config (build.rustflags or target.*.rustflags).

These only affect the compilation of the top crate.

@alexcrichton
Copy link
Member

I'd prefer to keep Cargo from parsing rustflags and trying to learn about specific flags, but Cargo already has intrusive knowledge of lto to fixing that seems reasonable to me!

@bluss
Copy link
Member

bluss commented Nov 3, 2016

codegen-units is the same kind of thing, isn't it. Nothing needs to be rebuilt.

In rustbuild, I would like it to not rebuild anything when -Ccodegen-units=x is added in rustflags. (Maybe rustbuild has some specific option for this).

@carols10cents carols10cents added A-linkage Area: linker issues, dylib, cdylib, shared libraries, so A-rebuild-detection Area: rebuild detection and fingerprinting C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-build labels Sep 29, 2017
@ehuss ehuss added the A-lto Area: link-time optimization label Jun 5, 2020
@jonas-schievink
Copy link
Contributor

We just ran into this one again. It seems that adding lto = true to the dev profile means that switching between cargo build and cargo build --tests will now rebuild the entire crate graph every time, which is pretty unfortunate (and was also fairly hard to track down to this issue).

I think this should be considered a bug instead of a feature request.

@ehuss
Copy link
Contributor

ehuss commented Sep 1, 2020

@jonas-schievink That sounds like a different issue. This issue is about changing the LTO setting. What you're mentioning sounds like a rebuild-detection issue when switching between commands. Can you file a new issue with a reproduction? Also, beware, there has been a recent change which might affect the behavior that will appear in the next nightly.

@jonas-schievink
Copy link
Contributor

@ehuss Okay, filed #8669

@epage epage added the S-needs-mentor Status: Issue or feature is accepted, but needs a team member to commit to helping and reviewing. label Oct 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-linkage Area: linker issues, dylib, cdylib, shared libraries, so A-lto Area: link-time optimization A-rebuild-detection Area: rebuild detection and fingerprinting C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-build S-needs-mentor Status: Issue or feature is accepted, but needs a team member to commit to helping and reviewing.
Projects
None yet
Development

No branches or pull requests

7 participants