From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <6c4047deda8f6556c4f68b34b8f78dd6@proxima.alt.za> <20111202143311.GD7640@dinah> Date: Fri, 2 Dec 2011 18:58:01 +0100 Message-ID: From: Francisco J Ballesteros To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Building Go on Plan 9 Topicbox-Message-UUID: 4c1ef808-ead7-11e9-9d60-3106f5b1d025 +1 for using parallel mkfiles. If they are few, we don't need to import gmake and we could still build just by adding them to the std tree. On Fri, Dec 2, 2011 at 6:55 PM, Lyndon Nerenberg wrote: >>> modify ape/make. > > > I was just waiting for this :-P > > Please do NOT fuck with ape/make. =C2=A0As the paper says, APE has become= more of > a tool to write conforming ANSI / POSIX code vs. porting the stuff to Pla= n > 9. =C2=A0Please don't take apes' virginity. > > If people insist on inflicting gmake upon us, fine. I guess. =C2=A0But pl= ease > (please?) don't screw the ape: deposit it in /$cputype/bin/gmake instead. > > And now that the camel is firmly in the tent, we might as well > create a /camel hierarchy to parallel /ape, for all the camel > cruft (i.e. /$cputype/camel/make vs. /$cputype/bin/gmake). > > Then, people who want to ride camels through the desert can run bsh(1) to > obtain a suitably inhospitable environment. =C2=A0(bsh as in baking-hot s= hell, > although bs(1) seems like a reasonable alternative.) >