On Wed, 2013-05-01 at 22:08 +0300, Eli Zaretskii wrote: > Yes. But I thought the change was about -Otarget, not -Ojob. Stefano > was complaining about a plain -O, so -Ojob is not what was his > problem.
Yes, it is about -Otarget. As I said, I added -Ojob output "just for completeness". The important distinctions (for this thread) are between -Otarget and -Omake. If you see the behavior I describe for those two flags then things are working as expected. If you still see choppiness in the output with -Otarget and you see the behavior I describe, I'd be interested to know more about the targets you're building. I'd also be interested to know if using -Otarget vs. -Ojob makes any difference in the choppiness. If your recipe normally runs for 5 seconds (say) and it continually generates output during that time, then yes, certainly the -O feature will result in choppiness because instead of a sequence of continuous output over 5 seconds you get 5 seconds of silence, followed by all the output. That is the nature of the beast... if this bothers you (more than having interleaved parallel output) best to not use -O. I suggest that for MOST makefile targets, this is not the normal behavior. Most makefile targets (building a .o for example) are built relatively quickly and, more importantly, they don't expect to see much output except on failure. I would also point out that the more output your targets generate the more likely you are to get output corruption when running with high -j, and the more you'd be likely to benefit from -O. > That is completely unexpected for me: I thought that -Otarget meant > that all the output from making a target, e.g. rec1, will be output as > a single unit. If that's not the intent, then why is it called > "target"? That IS the intent. However, in the presence of makefile recursion this model fails. Consider if you have a makefile, like every single automake makefile for example!, where the "top-level" target is nothing more than a recursive invocation of a sub-make with some extra arguments, and the sub-make actually does all the work: all: config.h $(MAKE) $(AM_MAKEFLAGS) all-recursive Now, if you do nothing special for recursive make, you'll get no output from the entire build until it is completely done, because all the output from the recursive make command is going to the temporary file for that target, then it all gets dumped at the same time. I think this makes the output sync feature much less useful: it's only appropriate for building in the background where no one looks at the output until it's done. If you want that behavior, though, that's exactly what the -Omake option selects so it's available. For -Otarget we introduce an exception to deal with this problem: if we detect we're about to invoke a recursive make, we do NOT redirect the output to the temp file. We let each target of that make print its output immediately. This way you don't have to wait for an entire recursive make to finish before you see any of its output. > Why is it important to make that exception? And shouldn't we have an > option _not_ to make such an exception, but without -Omake, > i.e. without waiting for the whole session to end? Whenever any > top-level recipe finishes, it is flushed to the screen as a single > unit. Does this make sense? I don't understand the change that you're suggesting. That's exactly what -Omake does today: whenever any recipe finishes it is flushed to the screen as a single unit, and no special handling is given to recursive makes. If we can improve on this I'm very interested to hear the details. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make