On Sat, Feb 15, 2014 at 12:48:44AM +0100, yac wrote:
> On Fri, 14 Feb 2014 11:02:49 -0500
> Emery Hemingway <emery@vfemail.net> wrote:
> > The default GOROOT that go looks at for base libraries seems to be
> > compiled in so this should be pretty easy, like python but simplier.
> 
> I'm not sure what you are trying to solve here. Afaik GOROOT is used to
> determine where to install and it can be overriden from env.

Not overridden, but extended. See go help gopath.

> > An eclass could look at a GO_MINIMUM variable and install for each
> > version go that is present and matches.
> 
> It might be good idea to learn from others who'd been through this and
> I think the new python eclasses are good ones, going with something
> like PYTHON_TARGETS array (GOLANG_TARGETS ?)
 
 I would prefer go_targets if this becomes an issue, but it isn't at
 this point because there is only one target, go1, and we do not know if
 there will be a go2 or not.

> > Dropping old versions of go
> > will be easy because linking wont break, and new releases should be
> > forwards compatible.
> 
> So far yes I think but I guess that may be quite different with in the
> future with >1.x, and "should be" so there may be corner cases where the
> user does need to use earlier version.

Highly unlikely in the context of go1, and again, we don't know if there
is going to even be a go2 or not. The only reason there will be a go2 is
if there needs to be a change at the source level which can only be done
in a backward incompatible way.

The question really should be, do we want a system-wide workspace to
store third-party libraries [1]?
and if so, where do we put it -- maybe /usr/lib/go-gentoo should exist
along side /usr/lib/go?

The catch would be that every time you upgrade dev-lang/go, everything
stored in /usr/lib/go-gentoo has to be recompiled because there is no
guarantee that the libraries we have there are compatible with each
minor release of go1, only the source.

Then, the executables we have in /usr/bin will still run, but it would
be good to rebuild them as well to get the new libraries linked into
them.

If we had a work space in, say, /usr/lib/go-gentoo, we could leave the
executables in there and symlink them to /usr/bin. If we did that, it
would be easy for a user to rebuild everything in the workspace for the
new go by doing

emerge /usr/lib/go-gentoo/bin

Thoughts?

William

[1] http://golang.org/doc/code.html