> From: Paul Smith <psm...@gnu.org> > Cc: stefano.lattar...@gmail.com, bug-make@gnu.org > Date: Fri, 03 May 2013 12:55:26 -0400 > > Suppose we do this: if we're about to invoke a line marked recursive and > we're in -Otarget mode, then before we run it we'll show the current > contents of the temp file (using the normal synchronized output > function).
Sounds good, I think we should try that. > This will ensure that output from lines before the recursive make will > be shown before the targets in the recursive make. It's not 100% > identical but I can't see any way to do better. Why isn't it identical? > Consider every target in the entirety of build, including all submakes > and all their targets as well, as one long list of targets (for example > the results of a serial build). The fraction of those targets that are > invoking sub-makes will be, at most, very small. That depends. I think you will find a different fraction in Emacs, especially when it bootstraps itself (which involves byte-compiling all the Lisp files in a 3-level deep recursion, the last of which passes to Make a very long list of files which all can be compiled in parallel; see lisp/Makefile.in in Emacs). > -Otarget wants to collect the output of each individual target, then > show the output for each target as soon as that target finishes. That's > what users (should) expect when using this option. > > In the case of recursive make targets, this presents an unsolveable > contradiction: how can you both show the output of EVERY target > (including the targets run by the submake) as soon as it completes, and > still not show the output of any target (including the targets that > invoke a submake) before it's complete? You can't do both! But I don't think there's a requirement to avoid showing incomplete output. The only requirement is not to mix output from two or more parallel jobs, that's all. I guess that brings us back to your suggestion above. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make