On Sat, Feb 15, 2014 at 12:48:44AM +0100, yac wrote: > On Fri, 14 Feb 2014 11:02:49 -0500 > Emery Hemingway <[email protected]> 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
signature.asc
Description: Digital signature
