Re: [gentoo-dev] dev-lang/go

[yac]

On Sat, 15 Feb 2014 16:44:09 -0600
William Hubbs <williamh@g.o> wrote:

> On Sat, Feb 15, 2014 at 12:48:44AM +0100, yac wrote:
> > On Fri, 14 Feb 2014 11:02:49 -0500
> > Emery Hemingway <emery@×××××××.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,

golang is more search friendly

> 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.

There still are different compilers at least, even if changing minor
version would be a non-issue. But I'm not familiar with those, I think
those are used for compiling for other than the supported archs (iirc
only x86 and x86_64)

> > > 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?

I assume you are talking about thirdparty packages installed by
portage, not by localy/manually by user. Well, without the system-wide
workspace to store the libraries, this whole go eclass would be kinda
pointless, no?

Currently /usr/lib/go/gentoo is used and I see no reason to change it.

>
> 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

Good idea.

> Thoughts?
>
> William
>
> [1] http://golang.org/doc/code.html



---
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B