sublime-rust + build.rs results in rebuilding all dependencies every build (clobbers state in target folder)

[MasonRemaley]

Versions

Sublime Text 3 (Build 3125)
Rust Enhanced 1.2.5
macOS 10.12.1
rustc 1.17.0-nightly (a559452b0 2017-03-17)

Problematic behavior

When using a build script and editing code with Sublime + sublime-rust, every time you save a file and then run cargo run, every dependency of your project is rebuilt.

If you turn off sublime-rust or edit in a different editor or such, this does not happen.

If after building with cargo you save your target folder somewhere else, wait until sublime-rust finishes it checks, and then restore it you can also avoid the problem. My guess is that sublime-rust isn't using the same version of rustc as me or is compiling with different settings, clobbering the saved output in the target folder. I'm not sure what the build script has to do with it.

I'm also seeing this a lot: Blocking waiting for file lock on build directory, I assume due to sublime-rust recompiling in the background, and taking a long time cause it's recompiling all the deps as well.

Steps to reproduce

1. Create a project with the following files. This is a pretty normal pattern for code generation, I basically copied it from the cargo docs.

src/main.rs

extern crate ctrlc; // Doesn't matter what the dependency is since we aren't gonna use it, we just want /something/ so we can see it get rebuilt unnecessarily 
include!(concat!(env!("OUT_DIR"), "/generated.rs"));

build.rs

extern crate itertools; // unused, just so we can see if it's rebuilt

use std::env;
use std::fs::File;
use std::io::Write;
use std::path::Path;

fn main() {
    println!("cargo:rerun-if-changed=build.rs");
    let out_dir = env::var("OUT_DIR").unwrap();
    let dest_path = Path::new(&out_dir).join("generated.rs");
    let mut f = File::create(&dest_path).unwrap();
    write!(&mut f, "fn main() {{ println!(\"Hello, World!\"); }}").unwrap();
}

Cargo.toml

[package]
name = "TestProj"
version = "0.1.0"
authors = ["Mason Remaley <redacted>"]

[dependencies]
ctrlc = "3.0.1"

[build-dependencies]
itertools = "0.5.9"

2. Build the project from the console (not via sublime-rust) via cargo build
3. Add a comment to main.rs using Sublime with sublime-rust installed and the feature that shows errors inline in Sublime turned on
4. Build the project again the same way, and see that ctrl-c (or whichever dependency you've added) gets rebuilt.
5. Now save the target folder somewhere else on your machine
6. Add another comment to main.rs
7. Wait for sublime-rust to finish building
8. Delete the resulting target folder, and then move the original one back
9. Do cargo run and observer hat it does /not/ rebuild all of the dependencies this time.

Let me know if you have any trouble reproducing/want any further help debugging.

[ehuss]

I can't quite reproduce this. The on-save syntax checking shouldn't alter any of the intermediate files in the target directory (it creates some extra fingerprint files, but those shouldn't interfere).

Should your example Cargo.toml look closer to this (I couldn't get yours to compile)?

[package]
name = "TestProj"
build = "build.rs"
version = "0.1.0"

[dependencies]
ctrlc = "3.0.1"

[build-dependencies]
itertools = "0.5.9"

Also, you say you are using nightly. How are you selecting the toolchain? Do you use "rustup override"?

When you say "Build the project", I assume you mean you are running Sublime's "Build" command? Are you using a variant like "Release"?

I also assume you have rust/cargo installed in ~/.cargo/bin and are using that. You don't have any environment variables like RUSTFLAGS set anywhere?

[MasonRemaley]

Whoops--was experimenting with whether or not both build dependencies and normal dependencies get rebuilt (they do) and pasted in incompatibles copies of the files. I've updated the original post with your fix.

I've also updated it to be more clear about how I'm building--I'm building from the console with cargo build/cargo run, not via sublime-rust. I suspect this is why you weren't able to recreate it.

Both rustc and cargo are in ~/.cargo/bin. I installed them by installing rustup, and doing rustup install nightly and rustup default nightly. I do have a couple of rust flags set:

export RUST_NEW_ERROR_FORMAT=true
export RUSTFLAGS="-Zincremental=target/incremental"
export CARGO_INCREMENTAL=1

I think that when I was debugging this earlier I turned them off to make sure they weren't affecting things. If you still aren't able to recreate this when building via the console I'll do that again to be sure.

[ehuss]

Yea, the only way I can reproduce this is when you compile from a terminal with RUSTFLAGS set. This is expected, as it changes the fingerprint enough for cargo to trigger a complete rebuild.

[MasonRemaley]

Ah, I didn't realize Sublime wouldn't build with the flags set in my ~/.bash_profile but I can see how that would cause this (to some extent, still not sure why the build script is needed). I tried it out without any environment variables set and it doesn't happen then. Is there any way to have the build from within Sublime use my environment variables?

I'm happy to just turn off rust_syntax_checking and the avoid the whole issue myself, but while it makes sense it is a pretty subtle thing to realize that the editor plugin is causing problem with compile times outside of the editor--it took me quite a while to realize this wasn't a bug in the latest release of Cargo or something. I could imagine someone newer to Rust just assuming that compile times always take that long if they happened to have some flags set.

[ehuss]

Yea, I'm working on something that will allow you to include environment variables manually. I'm also thinking about trying something like https://github.com/codexns/shellenv which would pull all the environment from your shell.

[dten]

had a similar mystery with macOS and the path. I'm not a regular mac user but it appears to me that if you set your path in ~/.profile and log off and log back in then changes do apply.
for me it was i could run adb from bash, but which could not find it, and any new process could not find it.

[ehuss]

That is perhaps because in build 3127 Sublime now reads your shell environment on OSX.

[dten]

Can we close this then?

[MasonRemaley]

Yup, I just checked with the current version of Sublime and it's now working correctly!