On Mon, Dec 30, 2013 at 12:48 PM, Emery Hemingway em...@vfemail.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
