From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri,  7 Jan 2011 11:40:21 +0100
From: Henning Schild <henning@plan9.bell-labs.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID: <20110107114021.5d86d2ad@harald.be.alcatel-lucent.com>
In-Reply-To: <AANLkTikEqb08gAGnkHbC0XosnOyqi==vRZVgQ1hpftVx@mail.gmail.com>
References: <AANLkTinwmuP0RjYz=FsFZQwOCBmj=sUurSJbC70BuDav@mail.gmail.com>
	<40711c3657e4203ed90a91ab770b3380@plug.quanstro.net>
	<AANLkTikEqb08gAGnkHbC0XosnOyqi==vRZVgQ1hpftVx@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] mk (from plan9ports) modification time resolution issue?
Topicbox-Message-UUID: 913c5530-ead6-11e9-9d60-3106f5b1d025

On Fri, 7 Jan 2011 10:51:56 +0100
Ciprian Dorin Craciun <ciprian.craciun@gmail.com> 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 costs less than a
second for each of these targets. If your project it full of them and
they are deps for bigger targets you may want to add "sleep x.y" to the
rules. That way it will maybe take more time but will idle instead of
wasting CPU-time. When using the sleeps adjusting NPROC might help to do
something useful while sleeping.

Another way i could think of is adjusting the mtimes using touch. So
touch the sources -1s or the target +1s after creation of the target.
Depending on the graph that might cause other trouble i guess.

Henning