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

[Rick \\\"Zero_Chaos\\\" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/30/2013 03:48 PM, Emery Hemingway 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.

You can fine go-mtpfs in portage already.  I packaged it, with a lot of
help. It's terrible.  Worst part, it can't reinstall.  You can install,
and uninstall, but if it is installed you can't install again (so emerge
- -e @world would fail).

By all means, have fun.

- -Zero

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSweOYAAoJEKXdFCfdEflKaf4QAK2JNcVGg4eSvVXpkkgdwKlO
xp3Dm8ao6Ly/DuqD1wSQUghsaCaw9yD0bzlnLOwGQkHhFhAxqj/wpyLdKAr6rQ64
YqtT5WIFdymuB/rSO+0D47zfyjQeFLUGbiiSLMTrTyqol2SexchlVu6mLKLDM0rX
pJctl4iERzHKHF7/xdQv90vBkUgQsRlN/YlGYUXO/6P5CDJU+T2+rGlps7yN/z+h
oaZrVJxNHExdTCbIhnpfKOVSiBisVG2dlwJKL0FFq9EhJph+hrxe9CaD8rMNKGkL
Suc/6rT4vFmBmb32/Lzy4x9dfxD6n12vwQBn8ZctJnoqfniVx96S4xmwrBtG3hNH
7JenDriuVUuIkUut45+okBUu829PDt0qs+LRRBQejf4DdnkFKJGg1W+97IwVGlTc
J/qz+sEdoLTD88zd145iMf79TonmDwDxGxoDEiGs69250TC0WWWnP0x799p0S7uq
+2iOunm2oRB2HAiGg/T/rC+C00/pE441ZWX/zXtDphVe3oOsQ8ieZOL/U62+vb6e
/VaUp9iTQrssRvRuIpvC0Oqt+2YGlUQHFEAHb/5HHTBFhrdZLyC3edai7+VNIEy3
UV6B82MY5sUDhHPY+b2RpVlrkuhN7AqZWebI7qapVzU3gg8liyE8LWW6uvgz7wTF
8BWuxvBPwaP/1RczKaeV
=Yv0m
-----END PGP SIGNATURE-----