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

[William Hubbs]

On Wed, Feb 19, 2014 at 12:34:22PM +0100, yac wrote:
> 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)

Also add arm to the supported list along with amd64/x86-fbsd.

The only other compiler is gccgo [1], but it is part of the gcc
toolchain, so I have no idea what they are doing there, or if our
toolchain guys are even supporting it. Also, if you look at the comments
on that page, it is a bit behind dev-lang/go. It is not clear to me
either whether gccgo works on other architectures, and whether it is a
compiler or a front end like the old cfront used to be for c++. Also, I
don't know whether it will even share the same libraries as dev-lang/go;
it may just use standard libraries stored in /usr/lib.

In short, I have no clue how gccgo works. ;-)

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

Well, I was suggesting go-gentoo to keep third party libraries out of
the standard go tree and based on the definition of a workspace from the
go documentation.


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


[1] http://golang.org/doc/install/gccgo