From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <867781d7baf5c4e270499faf93e19225@coraid.com> References: <6c4047deda8f6556c4f68b34b8f78dd6@proxima.alt.za> <20111202143311.GD7640@dinah> <867781d7baf5c4e270499faf93e19225@coraid.com> Date: Fri, 2 Dec 2011 15:12:25 -0700 Message-ID: From: andrey mirtchovski To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] Building Go on Plan 9 Topicbox-Message-UUID: 4c8628ac-ead7-11e9-9d60-3106f5b1d025 > if the rule is literally "zero change", then we should give up now. Russ has been most accommodating with changes in the Go tree. As far as go portability to Plan 9 is concerned, that's not a problem (except the few actual problems that need fixing, but that's just code). The issue is polluting the go tree with yet another build framework which is 1) not really necessary, 2) about to be taken out anyway and 3) possible to devise programatically. Russ has said privately (jokingly) that he'd accept mkfiles if each one said "|<$GOROOT/mkmk.rc Makefile" and, knowing what we know now, it's not impossible to do. rminnich-9go's mkfiles for the go package library were mostly created with such a script. more important issues exist than just how to build go (which boils down to "pick any of the 3 current methods and go for it") -- for example, in order to complete running the full test suite one needs to solve a signal handling bug in the plan9-specific code of the go runtime.