On Tue, Jan 18, 2011 at 18:28, Russ Cox 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 touchin
> 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 abo
On Fri, Jan 7, 2011 at 12:40, Henning Schild
wrote:
> On Fri, 7 Jan 2011 10:51:56 +0100
> Ciprian Dorin Craciun wrote:
>
>> :) I've kind of feared that this is the reason... :)
>>
>> But still how do people handle the issue?
>
>
> I guess in most cases it is ok to ignore the slight waste
On Fri, 7 Jan 2011 10:51:56 +0100
Ciprian Dorin Craciun wrote:
> :) I've kind of feared that this is the reason... :)
>
> But still how do people handle the issue?
I guess in most cases it is ok to ignore the slight waste of CPU-time.
And i guess people just ignore it. After all it cos
On Fri, Jan 7, 2011 at 11:25, erik quanstrom wrote:
> the code has its reasons. from mk.c:/^outofdate
>
> /*
> * Treat equal times as out-of-date.
> * It's a race, and the safer option is to do
> * extra building rather than not enoug
the code has its reasons. from mk.c:/^outofdate
/*
* Treat equal times as out-of-date.
* It's a race, and the safer option is to do
* extra building rather than not enough.
*/
return node->time <=
Hello all!
I've played today with mk (from plan9ports), and I thin I've
stumbled upon the following issue: if both the build of a prerequisite
and the target itself is less than a second (the same second), then mk
believes it must remake the target when invoked a second time.
See belo
