From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 22 Jul 2011 19:48:41 +0200 From: Lucio De Re To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20110722174841.GA2065@fangle.proxima.alt.za> References: <201107220536.p6M5agtv019617@freefriends.org> <20110722130310.GO1803@fangle.proxima.alt.za> <142CEA85-FE43-4D87-B08D-BF151422BC07@bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <142CEA85-FE43-4D87-B08D-BF151422BC07@bitblocks.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto) Topicbox-Message-UUID: 04c55fec-ead7-11e9-9d60-3106f5b1d025 On Fri, Jul 22, 2011 at 08:39:56AM -0700, Bakul Shah wrote: > > Is your goal to a) have the standard go distribution build on plan9 > with no changes or b) do a minimal infrastructure to make future ports > easy or c) do a one time port? > The crucial feature is that any changes to the Go distribution should slot into the Plan 9 port of Go as seamlessly as possible. What has happened to me a couple of times since Go was first released, is that I applied immense quantities of patching to my heart's content to the released Go sources, only to need to re-apply them, with similar difficulty only a few month laters, to a changed source base. I am pleased and extremely grateful that the number of such necessary changes has been reduced significantly, with Russ Cox's help, by incorporating these changes into the Go distribution. At this point, there are only two adjustments I believe will be hard to eliminate entirely, although I think now that the second has a simple solution. And, yes, there is a rather big carpet I have swept some items under and Russ has rejected corrections that would be really nice to have, in all case with a firm, but understanding hand. The end result is that after importing the Go distribution in toto into the Plan 9 repository I set up for it, the 386, arm and x64 C compilers, assemblers and linkers all are generated correctly on my Plan 9 platform. Untested except for 8l and no doubt with some imperfections, but I consider this progress. The code review process my patches are undergoing adds enough confidence that I'm willing to relegate testing to some time in the future when I have a more complete code base and the corresponding executable binaries. I have also made my life a touch harder by declining to use the APE environment, but the structure of the Go distribution makes that less of a burden than one may assume. > If it is c), why not just use the 9front port? If b) or a), why not > look at what they have done at the very least? > One reason for not looking at Taru's work (I guess it is feeble, but who is to know?) is that I don't know the status of its copyright; I have ceded copyright to the Go Authors (more accurately, I have filled the necessary paperwork to satisfy their legal requirements), but I can hardly apply that cession to Taru's work. For the rest, I have been alerted in private mail that Taru's work contains many adjustments whose intention was to get the code to compile. I have a similar code base and Erik Quanstrom has another. I know my early set of patches is totally inadequate today, I often refer to it in this phase of this project. I presume that Erik and Taru both will find their patches significantly out of sync with future Go releases before too long. As it may take me many months to get the project completed, I'd rather work in tandem with the Go runtime developers, who seem to have taken the same route as I have, namely to include their changes _in_ the Go distribution as they go along. > I'd first fix Make.* to use byacc, or even better, p9p yacc, and > run all the tests on a bsd and just fix %error-verbose. If they pass, > no need to port bison or may be even byacc. That's an interesting approach I had not considered. It involves considerable throw-away work, but it will be instructive. Right now my priority is to smooth out quite a few wrinkles in my repository, where the last batch of changes needs extensive rework, not all caused by Bison-itis. As soon as I have my head out of the water, I'll follow the much appreciated advice I have received from you all. ++L