Often there is a set of reasonable, alternative algorithms one may utilize to solve a problem. Then, there is a set of unreasonable algorithms one may employ that may or may not solve the problem given various conditions. "make" has a proven reasonable algorithm to solve the problem for which it was designed. It employs one algorithm among other possible, and equally good, algorithms. You are implying that mk is using another valid algorithm rather than an unreasonable one. I can't see it yet.

I'd be a better judge if I understood the purposeful, thought out reason behind the problems I am experiencing - assuming there is one. "That's just the way it works" or "we do it differently because we are not unix" are stupid as hell arguments.

I remain confident that there is a thought out, reasonable algorithm employed by mk that I am yet ignorant of.

Blake

On Wed, Dec 18, 2013 at 10:40 AM, Bakul Shah <bakul@bitblocks.com> wrote:

On Wed, 18 Dec 2013 10:11:22 CST Blake McBride <blake@mcbride.name> wrote:
> >
> > Somehow Unix or GNU "make" doesn't mix up buffered stdout with unbuffered
> > stderr output. They remain in order so the total out of make and all of
> > the commands are shown in order and in context. You know, so a human can
> > understand it. mk appears not to handle this the same. stdout output
> > and stderr output are totally out of sequence making it very, very
> > difficult to understand what is going on.
> >
> >
> mk should flush stdout after completion each command.

Just as plan9 is not unix, mk is not make. Rather than expect
it to behave like make, it pays to understand how mk works,
may be by experimenting with little mkfiles.