From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <69667ecfc3e88acb8b5495181c2e0eb9@proxima.alt.za> Date: Fri, 2 Dec 2011 09:21:06 -0800 Message-ID: From: ron minnich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] Building Go on Plan 9 Topicbox-Message-UUID: 4be7f196-ead7-11e9-9d60-3106f5b1d025 On Fri, Dec 2, 2011 at 12:49 AM, Francisco J Ballesteros wrote: > Well, that's actually the approach Ron would choose for nix. > IIRC, there were a bunch of mkfiles added to the std. go tree > to make it compile, but I may be mistaken. > Ron knows better. My first hope was pretty much what others have said here: parallel mkfiles to the Makefiles, because I expected they would change slowly if at all. Andrey and I did get this going, and a simple mk install in go/src sufficed to build and install all Go packages and produce some working binaries, however that approach is not going to be accepted, because it requires mkfiles in the Go source tree. For the record, it takes a surprisingly small amount of effort to make this work, once you know what is going on. Oh, and, there are some bugs in the Go source that are uncovered when one builds on NIX. I've submitted one fix and have one or two more in the works. The work has not been in vain. I think we need to be realistic about how much we can influence the Go mainline source. I keep seeing comments on 9fans about how we can change the way the Go source is written/built/managed, and those comments envision some signiifcant changes. To repeat, I have been told in no uncertain terms that changing the way Go is set up to accommodate great Plan 9 ideas is just not going to happen, and that our "footprint" in the Go source tree must remain very small. I think that is the correct approach on the part of the Go team. We have made minor changes on NIX to accomodate Go. Simple examples: /*/mkfile have an entry for the name of the Go compiler. There is a /go directory. Based on the Python experience, where Plan 9's python is always far behind the leading edge, I still believe that it is best if the following always worked: hg clone the-official-go-tree go cd go/src ./some-shell-script I do not think it makes sense to have Go source distributed as part of the Plan 9 distro or contrib mechanism as that approach has not worked well (in my view) for Python. Again, what I'd like to have is a Go that always builds on Plan 9 from the mainline go source tree, without having to dump in lots of patch files and other junk or change the Makefiles. Andrey and I worked toward a "build with zero changes" model. We did not get done and decided to wait for Go 1 anyway because the number of Makefiles will be greatly reduced in Go 1 -- I expect there will be less than 10 or so. I believe the Go authors will accept a single shell script or two and a go/9/include tree as part of the standard distro, so we need to think in those terms. What I have in go/9/include today are some u.h files, and that and a very simple set of changes should suffice to let us build Go on Plan 9 with *zero* changes from the standard go source. I hope that last paragraph was not too confusing. Thanks ron