From mboxrd@z Thu Jan 1 00:00:00 1970 From: dexen deVries To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Date: Thu, 30 Aug 2012 16:48:39 +0200 Message-ID: <1668160.8tJMjFT7TD@coil> User-Agent: KMail/4.9 (Linux/3.5.0-l45; KDE/4.9.0; x86_64; ; ) In-Reply-To: <0bdf5a16b73d486ae1a65fe61c8c6525@brasstown.quanstro.net> References: <0bdf5a16b73d486ae1a65fe61c8c6525@brasstown.quanstro.net> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Subject: Re: [9fans] rc's shortcomings (new subject line) Topicbox-Message-UUID: b4e743c2-ead7-11e9-9d60-3106f5b1d025 On Thursday 30 of August 2012 10:41:38 erik quanstrom wrote:=20 > what i was saying is that mk knows and insures that the output files > are there. the fact that it's not in the middle of the conversation = is > an implementation detail, imho. >=20 > that is, mk is built on the assumption that programs communicate thro= ugh > files; $O^c communicates to $O^l by producing .$O files. mk rules > know this. shouldn't be the case for rules with virtual targets (V). such rules ar= e=20 always executed, and the order should only depend on implementatino of = DAG=20 traversing. ``Files may be made in any order that respects the precedin= g=20 restrictions'', from manpage. if mk was used for executing grep in parallel, prerequisites would be a= ctual=20 files, but targets would be virtual; probably 1...$NPROC targets per=20= directory. anyway, a meld of Rc shell and mk? crazy idea. --=20 dexen deVries [[[=E2=86=93][=E2=86=92]]] I'm sorry that this was such a long lett=C2=ADer, but I didn't have tim= e to write=20 you a short one. -- Bla=C2=ADise Pasc=C2=ADal