[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/40115: make(1) behaviour is inconsistent across parallel and ordinary builds
On Dec 7, 11:02am, asau%inbox.ru@localhost (Aleksej Saushev) wrote:
-- Subject: Re: bin/40115: make(1) behaviour is inconsistent across parallel
| christos%zoulas.com@localhost (Christos Zoulas) writes:
| > This is not a bug. When -j is present, make tries to execute multiple
| > shell commands in a single shell instance for efficiency. This is not
| > very well documented in the man page, but -B gives a hint about it.
| > If you want to execute each line in its own shell process, use -B.
| > Most shell snippets that don't cd or chdir, benefit from the new way
| > of execution.
| I'd rather say, it isn't documented at all. The respective parts read:
| Try to be backwards compatible by executing a single shell per
| command and by executing the commands to make the sources of a
| dependency line in sequence.
| -j max_jobs
| Specify the maximum number of jobs that make may have running at
| any one time. Turns compatibility mode off, unless the B flag is
| also specified.
| That "try to be backwards compatible by executing a single shell per
| command" gives only a delicate hint, which is far from obvious. In my
| opinion "-j" part should mention it explicitly: "All commands associated
| with [particular? - fix style, please!] target are executed in single
| shell invocation."
| Why is it backwards compatible mode, which is on by default?
| Why don't make make run commands in single shell invocation
| and request explicit backward compatibility? Does it break
| too much code?
pmake was the make front end used by Sprint. If -j was specified, make
used "customs" a remote execution daemon to fork jobs on different
machines. It would have been very inefficient and difficult to control
to execute command by command on the remote system, so I guess they
chose to execute all the commands for a specified target in one shot.
Main Index |
Thread Index |