[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Regression caused by Commit: 5bd7ad2b225b ("Preserve the real value
Sven C. Dack
Re: Regression caused by Commit: 5bd7ad2b225b ("Preserve the real value of -jN in MAKEFLAGS using jobserver.")
Mon, 30 Oct 2017 12:14:05 +0000
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
On 30/10/17 07:33, Tim Murphy wrote:
For my money -j is always a top-level setting. To have it per
makefile and then let makefiles depend on that behaviour would open
the door to lots of scary bugs.
Agreed. Using -j in a Makefile is not portable, because it can cause a
system to run out of memory or just start an unwanted and excessive
amount of jobs.
However, if someone wanted to control the number of jobs from within a
Makefile then this shouldn't be discouraged either. Nor does make give
any kind of guarantees on how many jobs are started by other processes,
because this isn't something, which can be controlled easily from within
make, and I don't believe many expect such a form of control by make.
We do have flags such as -n, -k and -S, where users expect a strict
behaviour for -n, but not so for -k and -S (continue on errors, stop on
errors). The later two can both be set from within Makefiles, with -k
being potentially dangerous if set from within.
While I dislike the use of -j in Makefiles is it not as bad as if having
a (hypothetical) option to disable -n for example. As such do I see it
being in the same boat with -k. Any problems caused by using -j from
within Makefiles are the responsibility of the person who put it there.
It shouldn't be made a responsibility of the devs of make unless we have
very good reasons to do so.