Re: [bug #33138] .PARLLELSYNC enhancement with patch

[Frank Heckenbach]

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.