Allow a negative number of jobs to count from maximum number of cores

[orlp]

If you want your machine to remain usable during a compile session usually you want to set the number of jobs lower than your maximum number of cores. But this varies heavily from machine to machine, and makes it annoying to automate in bigger build scripts.

I would suggest extending the --jobs (or -j) parameter to negative numbers, where -j -1 would be 'all but one core', -j -2 would be 'all but two cores', etc. This makes it really easy for scripts to maintain a usable machine and scale to the number of cores available without having to look up the actual number of cores.

For sanity and convenience of automatic build scripts I would suggest that if -j was sufficiently negative to specify no or a negative amount of cores, to clamp the number of cores to at least 1, instead of giving an error.

So to be precise I would suggest changing jobs to i32 instead of u32 in BuildConfig::new (and wherever necessary to make that work) and replace this line with

let jobs = match jobs.or(cfg.jobs) {
    None => ::num_cpus::get() as u32,
    Some(j) if j < 0 => (::num_cpus::get() as i32 + j).max(1) as u32,
    Some(j) => j as u32,
};

I'm neutral on whether 0 should still not be allowed or whether that should be mapped to ::num_cpus::get().

[orlp]

Testing my pull request for this made me uncover this issue: https://github.com/rust-lang/cargo/issues/9219.

[orlp]

Not covered in my pull request:

• A fix for the aforementioned issue for jobs = 0 in the .cargo/config.
• Documentation for the new parameter behavior - I already felt the commandline docs were quite long. I don't know the best way to document this.
• A test such that if you specify e.g. --jobs -2 that cargo does in fact use N-2 parallel jobs, where N is the maximum number of CPUs. I feel this test would be quite involved and not worth the effort.

[epage]

Acceptance summary: this was discussed in the now-closed #9221

• While there is precedence for 0 being "all`, there isn't precedence for this
• alexcrichton was fine being a trailblazer with this and a FCP was started with a documentation concern being raised
• dtolnay did express interest in a more complex expression language for this. This hasn't been discussed further
• The original PR was closed due to inactivity

[the8472]

If you want your machine to remain usable during a compile session usually you want to set the number of jobs lower than your maximum number of cores.

Wouldn't running it under nice -n 19 cargo [...] or schedtool -B -e cargo [...] be a better approach? It would lead to better CPU utilization while still leaving foreground processes responsive.