bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: possible solution for -Otarget recurse (was: Re: Some serious issues


From: Eli Zaretskii
Subject: Re: possible solution for -Otarget recurse (was: Re: Some serious issues with the new -O option)
Date: Fri, 03 May 2013 21:15:10 +0300

> From: Paul Smith <address@hidden>
> Cc: address@hidden, address@hidden
> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]