GNU Make integration: Correctly react to the presence of `n` (`--just-print`) in `MAKEFLAGS`

[mbs-c]

Problem

Thanks to cargo implementing the jobserver protocol (#1744), you can already call cargo from a GNU make build and have both build systems figure out how many parallel jobs can be started at a given time. All you have to do is prefix the GNU Make recipe line in which cargo is invoked with a +.

Unfortunately, this has a nasty side effect: If you (or your IDE ¹) only want to know what GNU Make would execute and start make -n, then make executes cargo anyway, assuming that sub-makes will know how to handle the MAKEFLAGS appropriately. Unfortunately, cargo actually completely ignores the presence of n in MAKEFLAGS and starts building stuff, which is the exact opposite of what the user wanted.

Proposed Solution

If n is present in MAKEFLAGS, cargo should only print the processes it would normally execute instead of actually executing build processes.

Notes

Relevant GNU Make documentation:

• Instead of Execution (GNU make)
• MAKE Variable (GNU make)

Footnotes

1. CLion, for example, does this when importing Makefile projects ↩

[epage]

Could you provide a minimal yet complete reproduction case for this problem?

[mbs-c]

Sure, this problem is easily reproducible:

1. Run cargo init
2. Place a Makefile with the following contents in the newly created project:

all:
	+cargo build

3. Now run make --just-print

Expected behavior: The project is not actually built.
Actual behavior: The project is built.

[epage]

So + prefix seems to be about opting commands into the --just-print / dry-run mode. I've not messed with the jobserver side of make or cargo but I'm not seeing anything saying that that is required for jobserver to work for subprocesses. Is there something I'm missing or another reason you are using +?

[mbs-c]

To my knowledge, using + is required to make the jobserver communication work. The example Makefile in this comment probably explains it best: #1744 (comment)

Edit: I found the following paragraph in the documentation:

When using a simple pipe, only command lines that make understands to be recursive invocations of make (see How the MAKE Variable Works) will have access to the jobserver. When writing makefiles you must be sure to mark the command as recursive (most commonly by prefixing the command line with the + indicator (see Recursive Use of make). Note that the read side of the jobserver pipe is set to “blocking” mode. This should not be changed.

So, I guess it depends on the version of GNU make and the host OS.

[epage]

As the documentation for jobserver support in make didn't talk about + and talk of + was purely around dry-run, seems like we should extend our documentation at https://doc.rust-lang.org/cargo/faq.html?highlight=make#can-cargo-be-used-inside-of-make-or-ninja-or- to talk a bit about jobserver support and how to leverage it.

As for this, two more related pieces of documentation

• Jobs Sots
• Communicating Options to a Sub-make which talks about the programmatic structure of MAKEFLAGS for how it should be parsed

[epage]

While jobserver is a general protocol, the question then becomes if we should have built-in support for this more specific make functionality and what that means for any requests for support from any other build orchestrators.

[weihanglo]

BTW, if we even want to support this, some change might need to be made in https://crates.io/crates/jobserver in order to pass down the -n flag.