Re: [9fans] Problem with mk

[Blake McBride <blake@mcbride.name>]

[-- Attachment #1: Type: text/plain, Size: 1765 bytes --]

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.
>
>

[-- Attachment #2: Type: text/html, Size: 4018 bytes --]