Re: [9fans] Building Go on Plan 9

[ron minnich <rminnich@gmail.com>]

On Fri, Dec 2, 2011 at 12:49 AM, Francisco J Ballesteros <nemo@lsub.org> 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