Re: bin/40115: make(1) behaviour is inconsistent across parallel and ordinary builds

[christos%zoulas.com@localhost (Christos Zoulas)]

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:
| 
| -B
|    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.

christos