cargo check should be able to run in parallel to cargo build/run

[Boscop]

My usual workflow is to use Ctrl-B in Sublime to do cargo check and in a separate cmd window have cargo watch -x run running so that it always runs the latest version of my application.
But the problem is, both commands demand exclusive access to the build, and often, when I press Ctrl-B, cargo watch -x run is faster in acquiring the lock than the cargo check spawned by Sublime, and then I have to wait for a minute before the check runs and another minute before I can get the errors highlighted inside my source..
This is very frustrating, it should be possible to run both in parallel.

[ehuss]

I believe one solution to this is to set the environment variable CARGO_TARGET_DIR to a different directory so the two can run independently. For example, in Sublime, set the environment variable to something like "target-check" (see these docs for an easy way to set environment variables). Then make sure the watcher ignores the directory (something like cargo watch -x run -i target-check). The two now have different target directories and won't interrupt each other. The downside is that you will be essentially compiling everything twice concurrently.

Edit: This is essentially the same as #5148.

[Boscop]

Thanks.

Just to clarify, isn't it compiling everything twice already, once for check and once for build? After doing check, when I run build, it doesn't seem to use the results of check and does everything again.
So how would it be a disadvantage to do this concurrently?

[avkonst]

Compiling twice is a downside, my machine burns CPU a lot. But I can live with it for a while. Intelij uses a lot more anyway.
Note -i option does not work for cargo watch. Add it to gitignore instead.

[Boscop]

@ehuss So I just have to create a .sublime-project file in the project folder (if it should only apply to the current project) or edit RustEnhanced.sublime-settings (to apply it to all projects) and add this entry?:

    "env":
    {
      "Windows": 
      {
        "CARGO_TARGET_DIR": "target-check"
      },
      "Darwin": 
      {
        "CARGO_TARGET_DIR": "target-check"
      },
      "Linux": 
      {
        "CARGO_TARGET_DIR": "target-check"
      }
    }

@avkonst So you are also running into this issue? watchexec/cargo-watch#82
Are you on Windows 8.1 too?

[passcod]

Err, if "the -i option is not working", can you please please please record a --debug run and report it back on watchexec? We can't get this fixed without a reproduction, and neither me nor mattgreen (maintainer of watchexec) have managed to get one on our own. Something is obviously wrong, but we can't fix what we can't see.

[ehuss]

So I just have to create a .sublime-project file....

If you want persistent per-project settings, you'll need to run Project > Save Project to create a .sublime-project file.

I'd recommend running the Rust: Configure Cargo Build command to set the environment variables, since it will get the syntax correct, and let you choose where to set it. Your example isn't correct, it would be something like this for a project file:

{
    "folders": [ { "path": "." } ],
    "settings": {
        "cargo_build": {
            "variants": {
                "check": {
                    "env": {
                        "CARGO_TARGET_DIR": "target-check"
                    }
                }
            }
        }
    }
}

[epage]

We have #3501 for reusing information between cargo check and cargo build.

Even without that, one area they can't run in parallel is for build scripts in the dependency tree. #4001 requests distinct build scripts between check/build so that could change.

Handling the locking for running these in parallel would be messy but maybe the target directory changes we want for #5931 could help.

Overall, I lean more towards people using distinct CARGO_TARGET_DIRs rather than trying to get things to work for us to build these separately especially if we want to share more in the future.