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

[Alec Warner]

On Mon, Dec 30, 2013 at 12:48 PM, Emery Hemingway <emery@×××××××.net> wrote:

> I really like working with Go, and would like to see a means of merging
> Go packages with Portage. In short I am asking if anyone else is
> interested in a Go project.
>
>
> For those who aren't familiar with Go, I will sumarise why Portage and
> Go do not play well together.
>
> Go is static linked by default.
> The Go compiler creates static libraries and binaries. Libraries
> compilied with different versions of Go (1.1/1.2) may not be linked
> into the same binary.
>
> It is possible to compile dynamicly and that may involve using the
> GCC frontend, which is probably less tested and less optimized.
>
>
> Go libraries are usually unversioned.
> Libraries outside the system library are resolved with an import
> statement that specifies a source code repository, such as a git or
> mecurial repository. Most often Go libraries are installed using the
> 'go get' tool that clones a repository, and simply assumes HEAD/tip is
> the best revision to build against. There is some support for using git
> tags but it is not well documented. Often these libraries are very
> small for the sake of reuse and to keep APIs simple.
>
> If all that sounds bad, thats because it is. Is it worth versioning
> many tiny libraries or do we simply cache the repositiories and blame
> upstream when things stop compiling?
>
>
> A have made an eclass for Go and an ebuild for the bitcoin node written
> in pure Go to atleast prove that all this is possible. These are in the
> 'emery' overlay:
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=eclass
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=dev-go
>
> http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=net-p2p/btcd
>
> The eclass it a bit of a mess but it works, having done that, I would
> say that making ebuilds for every go library is tedious, but can be
> done almost entirely with boilerplate, almost every time.
>
>
Don't we basically do this with perl and g-cpan?


> The eclasss installs go source and static libraries
> to /usr/lib/go/gentoo (source code and .a library are required to link).
> The problem is when Go is updated, this folder may get wiped out, and
> if it isn't, those libraries will be incompatable with the new release
> anyway.
>

Can we version the shared objects in the golang they were compiled for?

/usr/lib/go/gentoo/GO_TOOLCHAIN_VERSION/...


>
> The other solution I see is to make a Go directory in /var/cache or
> something like it and just manage it as a cache. Libraries may come and
> go but that is fine. Bare repositories may be cached in DISTDIR just
> like the git and mercurial eclasses do. Doing things this way may
> require a specific utility for Portage that wraps the Go toolchain,
> which I would be willing to create. This utility could probably
> automatically resolve and fetch the libraries that are required as
> opposed to making an ebuild for each library, but that raises the
> problem of assuming the developers of each library maintain consistant
> quality and security.
>

I feel like this is not a great idea. What your idea as proposed reads like
to me is 'hey i want to move some libraries into /var/cache..cause you
know...we can delete the libraries at any time...and we can just recompile
them!'


>
>
> The problem is Go makes it trivial to build from source, but it does
> that in a very different and less precise way than Gentoo. There is
> always the option of build bots and installing binaries to /opt...
>
>
> Emery
>
>