Paul Smith wrote:
> The first one I've seen but hadn't had time to debug. I'll look at your
> patch. I left the truncate where it was rather than doing it after the
> sync_output() because I was hoping to avoid truncating a file that we'll
> never use again anyway, but I guess it isn't a big deal.
One could probably optimize it to avoid truncating if it's not going
to be reused, but I'm not sure it's worth the effort (including
future maintenance).
> COMMANDS_RECURSE _does_ mean to recurse. The reason for the '+'
> prerequisite is to tell make that this line, even though it may not look
> like it, will run a recursive make.
OK, let me just say that the meaning of "recursive" may not be
perfectly clear. Though the manual says: "The @samp{+} prefix marks
those recipe lines as ``recursive'' so that they will be executed
despite use of the @samp{-t} flag.", the example immediately
preceding this sentence has:
+touch archive.a
+ranlib -t archive.a
which are clearly not recursive make invocations.
I gather that make uses recursive in a wider sense as "anything to
be run regardless (because it probably arrages by itself not to do
anything serious in a dry run or so)", while the current
implementation of output-sync uses it in the more specific meaning
of a recursive invocation of GNU make (which will do its own
syncing).
Similar concerns seem to apply to other places where
COMMANDS_RECURSE is checked, e.g. (right after the output-sync code
in question):
/* If we aren't running a recursive command and we have a jobserver
pipe, close it before exec'ing. */
if (!(flags & COMMANDS_RECURSE) && job_fds[0] >= 0)
{
close (job_fds[0]);
close (job_fds[1]);
}
I don't think those touch and ranlib commands above need the
jobserver pipe (though, of course, this one doesn't hurt much, just
costs 2 available fds).
> Since make doesn't parse the command line it can't know for sure which
> ones actually recurse. It uses a heuristic, by looking for $(MAKE) or
> ${MAKE} in the unexpanded line. But this is easily defeated if your
> sub-make invocation doesn't use that variable for some reason. Hence,
> using "+" to force it.
If this is the actual intention, and the example is really a misuse
of the feature (maybe not ideal to put this in the manual then?),
this means indeed that "+" lines are exempt from output
synchronization and I see no easy way around it.
A (hypothetical?) use case would be another make-like tool which is
invoked from a Makefile. Unless it implements its own output-sync,
compatible with ours, its output remains unsynced.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
