From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <34270f8ddb3fc06e71d4db496a891dd4@brasstown.quanstro.net> References: <3e1e9e6fbfa856a01013a2f51b8d244f@coraid.com> <34270f8ddb3fc06e71d4db496a891dd4@brasstown.quanstro.net> Date: Thu, 19 Dec 2013 08:52:48 -0600 Message-ID: From: Blake McBride To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=20cf301d3cecafbfed04ede45027 Subject: Re: [9fans] mk time-check/slice issue Topicbox-Message-UUID: a0c94362-ead8-11e9-9d60-3106f5b1d025 --20cf301d3cecafbfed04ede45027 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 18, 2013 at 11:40 PM, erik quanstrom wrote: > > > to be more explicit. if a is built from b and mtime(a) <= mtime(b), then > mk could fail to rebuild a when it needs to. for correctness, mk must > use <= > not <. > I was thinking about the problem and actually, at least in all circumstances I can think of, changing that one operation from <= to < would fix the problem. If the times are on the same second, I would never have had time to change it. This would fix the problem. Perhaps this functionality can be controlled by an environment variable like NPROC. I think this is important as follows. If you are working on a project, edit some files, and then perform a mk, if files you haven't changed get built, I for one would constantly question myself, about whether or not I changed that file. It would make things confusing. Also, and perhaps more importantly, it may occur that a very long build is dependant on a very short preceding build. So, the unnecessary rebuild of the fast process can unnecessarily trigger the very long process. This really needs addressing for that reason especially IMO. Thanks. Blake --20cf301d3cecafbfed04ede45027 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On W= ed, Dec 18, 2013 at 11:40 PM, erik quanstrom <quanstro@quanstro.net> wrote:

to be more explicit. =A0if a is built from = b and mtime(a) <=3D mtime<= /span>(b), then
mk could fail to rebuild a when it needs to. =A0for correctness, mk must use <=3D
not <.

I was thinking a= bout the problem and actually, at least in all circumstances I can think of= , changing that one operation=A0from <=3D to < would fix the problem.= =A0If the times are on the same second, I would never have had time to cha= nge it. =A0This would fix the problem. =A0Perhaps this functionality can be= controlled by an environment variable like NPROC.

I think this is important as follows. =A0If you are wor= king on a project, edit some files, and then perform a mk,=A0i= f files you haven't changed get built, I for one would constantly quest= ion myself, about whether or not I changed that file. =A0It would make thin= gs confusing. =A0Also, and perhaps more importantly, it may occur that a ve= ry long build is dependant on a very short preceding=A0build. =A0So, the un= necessary rebuild of the fast process can unnecessarily trigge= r the very long process. =A0This really needs addressing for that reason es= pecially IMO.

Thanks.

Blake

--20cf301d3cecafbfed04ede45027--