bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Regression caused by Commit: 5bd7ad2b225b ("Preserve the real value


From: Sven C. Dack
Subject: Re: Regression caused by Commit: 5bd7ad2b225b ("Preserve the real value of -jN in MAKEFLAGS using jobserver.")
Date: Mon, 30 Oct 2017 12:14:05 +0000
User-agent: 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.

Regards,

Tim

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.

Cheers,
Sven




reply via email to

[Prev in Thread] Current Thread [Next in Thread]