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

esp-idf-sys gets recompiled every time when using rust-analyzer/clion #113

Open
mqus opened this issue Jul 23, 2022 · 6 comments
Open

esp-idf-sys gets recompiled every time when using rust-analyzer/clion #113

mqus opened this issue Jul 23, 2022 · 6 comments

Comments

@mqus
Copy link

mqus commented Jul 23, 2022

===================================
UPDATE: This solution seems to work:

I encountered this issue as well and I think I solved it by overriding the following setting in vscode: "rust-analyzer.cargo.buildScripts.overrideCommand": [ "cargo", "+esp", "check", "--quiet", "--workspace", "--message-format=json", "--all-targets" ]

I used the example command as advised in rust-analyzer.cargo.buildScripts.overrideCommand and added the argument +esp to run build scripts with the esp toolchain. This seems to have resolved the issue.

===================================

I created a new esp32 project derived from the demo project.

Now while developing it in clion, I run cargo check and cargo build frequently. But every time, even when I just changed the most simple things (like changing a string), cargo started to recompile a few more crates than just my own:

$ cargo check
   Compiling bindgen v0.59.2
   Compiling embuild v0.29.3
   Compiling esp-idf-sys v0.31.6
   Compiling esp-idf-hal v0.38.0
   Compiling esp-idf-svc v0.42.1
   Compiling p3-rust v0.0.1 (/home/user/projects/p3-rust)
warning: unreachable statement
[...]

This always takes ~20s longer than just compiling my small project and I would expect that those do not have to be recompiled every time, or even at all.

After asking on Matrix, @ivmarkov mentioned that he had similar issues when using rust-analyzer, but not on all machines.
In response to that, I disabled the option to run cargo check automatically within clion. After that, cargo (as started manually) behaved as expected.

I'm not entirely sure if this project is the right one to report this though.

@MabezDev
Copy link
Member

I've also seen this happen with rust-analyzer, to the point where I disabled it for esp-idf based projects. Would be great to figure this out.

@MabezDev
Copy link
Member

MabezDev commented Aug 2, 2022

Haven't had a chance to test but this setting might help:

rust-analyzer.cargo.buildScripts.useRustcWrapper (default: true)

Use RUSTC_WRAPPER=rust-analyzer when running build scripts to avoid checking unnecessary things.

@Xirado
Copy link

Xirado commented Feb 27, 2023

This is still a major issue. Building takes over 1 minute when changing even the slightest thing.

Edit: Here's the output of cargo build -vvv, if that helps: https://hastebin.de/ufeyimusof.yaml

Haven't had a chance to test but this setting might help:

rust-analyzer.cargo.buildScripts.useRustcWrapper (default: true)

This didn't seem to change anything

@jasta
Copy link
Contributor

jasta commented Mar 1, 2023

This was happening to me and I root caused it to running some cargo commands on the command-line in terminals that had different build.rs-sensitive env variables (like LIBCLANG_PATH) set. This caused cargo to think some build key changed and rebuild a bunch of stuff. To fix, I just make sure I put all my various export.sh-type things I need in .bashrc so that it's consistent between the terminal that launches clion and the ones that run cargo.

You should be able to prove this is the same issue for you by closing clion and anything else that might randomly run cargo then cargo build and check in a single terminal after changing small things and observe that no rebuilds occur. Then open just clion and try doing the same. You might also check that your clion config isn't doing something fishy like running custom build commands that affect build.rs-sensitive files.

@Xirado
Copy link

Xirado commented Mar 1, 2023

This was happening to me and I root caused it to running some cargo commands on the command-line in terminals that had different build.rs-sensitive env variables (like LIBCLANG_PATH) set. This caused cargo to think some build key changed and rebuild a bunch of stuff. To fix, I just make sure I put all my various export.sh-type things I need in .bashrc so that it's consistent between the terminal that launches clion and the ones that run cargo.

You should be able to prove this is the same issue for you by closing clion and anything else that might randomly run cargo then cargo build and check in a single terminal after changing small things and observe that no rebuilds occur. Then open just clion and try doing the same. You might also check that your clion config isn't doing something fishy like running custom build commands that affect build.rs-sensitive files.

In my case it's VSCode rust-analyzer, and i've already tried closing it and running it solely from the Terminal, and it didn't change anything for me.

@karlri
Copy link

karlri commented Jun 25, 2023

I encountered this issue as well and I think I solved it by overriding the following setting in vscode:
"rust-analyzer.cargo.buildScripts.overrideCommand": [ "cargo", "+esp", "check", "--quiet", "--workspace", "--message-format=json", "--all-targets" ]

I used the example command as advised in rust-analyzer.cargo.buildScripts.overrideCommand and added the argument +esp to run build scripts with the esp toolchain. This seems to have resolved the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

No branches or pull requests

5 participants