On Thu, 2013-05-02 at 20:24 +0300, Eli Zaretskii wrote: > The "desired results" in my original use case are that the output of > remaking each target is shown as one chunk in the order in which it is > expected, i.e. from the first command to the last. "Remaking a > target", a.k.a. "recipe" in this context are all the commands that > rebuild a single target. E.g., in this snippet: > > foo: bar > cmd1 > cmd2 > $(MAKE) -C foo something-else > cmd3 > > all the 4 commands and whatever they emit should be output in one go, > and in the order they are in the Makefile.
This is the way -Omake works. If you want that, you should set -Omake. > The "desired results" in the example you showed, i.e. > > > all: config.h > > $(MAKE) $(AM_MAKEFLAGS) all-recursive > > are that -O is in effect only for the sub-make which runs > all-recursive. I'm not sure what you mean by "ONLY for the sub-make" but if I understand correctly this is the way -Otarget works. So, you can have either method. Maybe what you're suggesting is that you want BOTH methods, but for different targets, in the same build? Today we don't support that. This is what I was talking about when I referred to a new prefix character on a per line basis to turn on/off ordered mode. I think trying to control this through the command line, by choosing different MAKELEVEL values to behave differently, is not a good solution. However I don't want to go there yet. It's a big, disruptive change and I'm not convinced that (a) we can't do something to obviate it and (b) even if we can't that the use-case is important enough to justify it. The build still behaves just as it did before, it's just that in your original case the output is shown in a strange order. > > In general I see no benefit in trying to special-case any particular > > level of make. For some builds the top level does all the work. For > > some the second level. For some the third. For many, different levels > > for different parts of the same build. > > The user always knows what she is going to run, or at least ought to > know. I think we already established that blindly appending -O to the > Make command might cause surprising and even disappointing or annoying > results, if one does it for a use case that does not play well with > this feature. So some degree of adaptation between -O and its > sub-modes to the depth and "breadth" (in parallelism sense) of the > build is necessary anyway. I don't think I agree with much of the above. But it's a matter of opinion so we'll just have to wait and see. > > > > 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. > > > > > > In my case, I see all the output at once. Maybe I misunderstand what > > > -Omake is supposed to do, too. > > > > I think you and I said the same thing: the output from recursive makes > > is saved up and flushed all at once...? > > No, that's not what I said. I said whenever a _recipe_ finishes, not > whenever the entire Make run finishes. -Omake only has any relevance when doing recursive makes. If you run "make -Otarget" and "make -Omake" in a non-recursive make environment, you will get identical behavior. The one and only difference between them is that when running a recursive make, -Otarget WILL NOT capture the output of the sub-make, leaving whatever it prints going to the same stdout as the parent make, and -Omake WILL capture the output of the sub-make in the temporary file, to be dumped after the recipe is complete. There's no -O mode which will save up the entire output of a non-recursive make and dump it all at the end. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
