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