make question

Hartmut Brandt hartmut.brandt at dlr.de
Thu Apr 28 16:04:19 UTC 2011


Hi Roman,

On Wed, 27 Apr 2011, Roman Divacky wrote:

RD>You seem to have messed with bsd make so I have a question for you  :)

Yeah, that was some time ago ...

RD>When a job is about to be executed in JobStart() a pipe is created with
RD>its ends connected to job->inPipe/job->outPipe. When the job is actually
RD>created in JobExec() the ps.out is set to job->outPipe so that in
RD>JobDoOutput() we can read from that pipe and basically just parse the output
RD>for shell->noPrint and leaving it out from the output. This is meant (I think)
RD>for supressing the "filter" thing. Ie. that if we do some @command the
RD>restoration of setting of quiet mode is filtered out.
RD>
RD>
RD>In -B mode we do it differently, as we invoke one shell per command we don't
RD>have to insert quiet/verbose commands and thus avoid all the piping/parsing
RD>dance.
RD>
RD>So my question is - why don't we invoke one shell per command by default
RD>and avoid the piping/parsing? Is this because of performance? I think that
RD>the piping/parsing of the output can have worse impact than invoking a shell
RD>for every command. Especially given that most targets consists of just one
RD>command.

The answer is in /usr/share/doc/psd/12.make. This is so one can write 
something like

debug:
	DEBUG_FLAGS=-g	
	for i in $(SUBDIR); do
		$(MAKE) -C $$i all
	done

instead of:

debug:
	DEBUG_FLAGS=-g \
	for i in $(SUBDIR); do \
		$(MAKE) -C $$i all ; \
	done

-B means 'backward compatible' and does what the original v7 make did: one 
shell per command. This means you don't have to write the backslashes and 
the shell variable will be seen in the sub-makes and programs.

I think we can change this, because it would break makefiles that assume 
that the entire script is given to the shell in one piece.

harti


More information about the freebsd-hackers mailing list