Disable broken Make jobserver support on OSX to fix parallel builds

[kesyog]

On OSX, CMake spawns child processes via libuv, which uses the Apple-specific posix_spawn attribute
POSIX_SPAWN_CLOEXEC_DEFAULT. This attribute blocks child processes, including make, from inheriting all non-stdio file descriptors from the parent process, including those of the Cargo jobserver.

Because make is passed jobserver information via MAKEFLAGS but is unable to access the jobserver, it prints the error shown below and proceeds to run a single-threaded build:

make: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.

As a workaround, disable jobserver support on OSX so that cmake-rs instead passes --parallel $NUM_JOBS to CMake, allowing for a faster, multi-threaded build.

Fixes #177

[NobodyXu]

Note that newer jobserver protocol supports fifo, which passes a path to the filesystem instead of fds.

Jobserver already supports this but I believe it's not the default.

[kesyog]

Note that newer jobserver protocol supports fifo, which passes a path to the filesystem instead of fds.

Jobserver already supports this but I believe it's not the default.

Yes, but as you noted in rust-lang/cargo#13483 (comment), this is unlikely to change in Cargo for backwards compatibility reasons. The named pipe jobserver isn’t supported by older versions of make.

An alternate approach I considered is to call make directly rather than cmake --build (for make builds only) so that the jobserver fd’s are forwarded correctly.
However:

• Using cmake --build is more portable
• We'd have to translate some options meant for cmake into the relevant make arguments, essentially replicating cmake --build functionality
• It’d be a breaking change that would make build_arg awkward to define and use. Edit: this is wrong, as build args are passed to the build executable (e.g. make), not cmake.

[NobodyXu]

I think it's possible for cargo to inherit jobserver?

I.e. a newer version of make creates a fifo and passes it to cargo, cargo passes it to build-script

[kesyog]

Based on https://github.com/rust-lang/cargo/blob/master/src/cargo/core/compiler/build_runner/mod.rs#L93-L110, I think you're right. Cargo will first try to inherit a jobserver if available and will otherwise create a file descriptor-based jobserver. While the default version of make on macOS Sequoia predates FIFO-based jobservers, one could theoretically have installed a newer version of make and be using a nested Cargo instance within a make job.

While this feels like a niche use case, we could handle this without much added complexity by allowing jobserver usage on OSX if and only if CARGO_MAKEFLAGS indicates we are using the FIFO-based jobserver protocol. Let me take a stab at that.

[kesyog]

I updated the commit to add an exception that allows the jobserver on macOS iff the jobserver is based on a named pipe/fifo

[NobodyXu]

Thanks for adopting my advice!

Not a maintainer but I have another nit suggestion regarding fifo checking:

[NobodyXu]

Thanks for taking my advice!

I'm not a maintainer so you would need to get someone else to review & merge it

[kesyog]

Thanks for the review @NobodyXu

@tgross35 any chance you could help get this merged and tag a new crate version?

[kesyog]

@tgross35 any chance you could help get this merged and tag a new crate version?

Or perhaps @thomcc based on #127 (comment) and https://www.rust-lang.org/governance/teams/library? Hopefully not being too spammy here.

[tgross35]

Thom knows this crate better so probably a better reviewer, but I can merge this if we don't hear back in a few days.

[kesyog]

@tgross35 mind taking another look?

[tgross35]

One question but this seems reasonable to me. @madsmtm you may want to take a look as well, since it touches builds on Apple platforms.

[tgross35]

The linker_messages failure stopped CI, have to wait for the next nightly to release.

[tgross35]

Released in 0.1.53 #233