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