[prev in list] [next in list] [prev in thread] [next in thread] 

List:       9fans
Subject:    Re: [9fans] mk (from plan9ports) modification time resolution issue?
From:       Ciprian Dorin Craciun <ciprian.craciun () gmail ! com>
Date:       2011-01-18 18:24:54
Message-ID: AANLkTimbAAo5Htm4fRCxEsdLtPM+tO45gDi8zvza761k () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jan 18, 2011 at 18:28, Russ Cox <rsc@swtch.com> wrote:
>>    But the above statement is true unless you have about 367 targets
>> (for quite a small project -- only 2 tiny and 1 larger Erlang
>> applications), which when built takes about 45 seconds (with
>> NPROC=16), and the second time (without touching a single file in the
>> source directory) takes about exactly the same amount (still 45
>> seconds), the third time goes down to 44 seconds, then 43 seconds,
>> then 7 seconds, then 1 second, then 0.6 seconds, then 0.2 seconds,
>> then again 0.2 seconds, again 0.2 seconds, again 0.2, again 0.2, again
>> 0.2, and finally after ONLY 13 builds it finds out that nothing is to
>> be made...
>
> sleep 1; mk
>
> Russ


    `sleep 1 ; mk` doesn't work.

    For example (I put the name of the target and the timestamp in
brackets as in: `target(timestamp)` I assume that each target takes
under one second).

~~~~
initial timestamps: a(2), b(1), c(1), d(1)
rules: b : a | c : b | d : c
or the graph: a -> b -> c -> d

first time I call mk:
    a(2), b(x), c(x), d(x)

second time I call mk after a sleep > 0:
    a(2), b(x), c(x+t1), d(x+t1)

third time I call mk after another sleep > 0:
    a(2), b(x), c(x+t1), d(x+t1+t2)
~~~~

    As a consequence I have to run `sleep 1 ; mk` a number of times
comparable with the longest path from input to output.

    Ciprian.

    P.S.: Even if for example `c -> d` takes 1 minute it is still
going to be runned twice until timestamp(c) > timestamp(b) (which is
only after the first sleep).


[prev in list] [next in list] [prev in thread] [next in thread]