Gentoo Archives: gentoo-dev

From: Emery Hemingway <emery@×××××××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] dev-lang/go
Date: Mon, 30 Dec 2013 20:48:34
Message-Id: 20131230154817.34a69433@ciguri
1 I really like working with Go, and would like to see a means of merging
2 Go packages with Portage. In short I am asking if anyone else is
3 interested in a Go project.
6 For those who aren't familiar with Go, I will sumarise why Portage and
7 Go do not play well together.
9 Go is static linked by default.
10 The Go compiler creates static libraries and binaries. Libraries
11 compilied with different versions of Go (1.1/1.2) may not be linked
12 into the same binary.
14 It is possible to compile dynamicly and that may involve using the
15 GCC frontend, which is probably less tested and less optimized.
18 Go libraries are usually unversioned.
19 Libraries outside the system library are resolved with an import
20 statement that specifies a source code repository, such as a git or
21 mecurial repository. Most often Go libraries are installed using the
22 'go get' tool that clones a repository, and simply assumes HEAD/tip is
23 the best revision to build against. There is some support for using git
24 tags but it is not well documented. Often these libraries are very
25 small for the sake of reuse and to keep APIs simple.
27 If all that sounds bad, thats because it is. Is it worth versioning
28 many tiny libraries or do we simply cache the repositiories and blame
29 upstream when things stop compiling?
32 A have made an eclass for Go and an ebuild for the bitcoin node written
33 in pure Go to atleast prove that all this is possible. These are in the
34 'emery' overlay:
39 The eclass it a bit of a mess but it works, having done that, I would
40 say that making ebuilds for every go library is tedious, but can be
41 done almost entirely with boilerplate, almost every time.
43 The eclasss installs go source and static libraries
44 to /usr/lib/go/gentoo (source code and .a library are required to link).
45 The problem is when Go is updated, this folder may get wiped out, and
46 if it isn't, those libraries will be incompatable with the new release
47 anyway.
49 The other solution I see is to make a Go directory in /var/cache or
50 something like it and just manage it as a cache. Libraries may come and
51 go but that is fine. Bare repositories may be cached in DISTDIR just
52 like the git and mercurial eclasses do. Doing things this way may
53 require a specific utility for Portage that wraps the Go toolchain,
54 which I would be willing to create. This utility could probably
55 automatically resolve and fetch the libraries that are required as
56 opposed to making an ebuild for each library, but that raises the
57 problem of assuming the developers of each library maintain consistant
58 quality and security.
61 The problem is Go makes it trivial to build from source, but it does
62 that in a very different and less precise way than Gentoo. There is
63 always the option of build bots and installing binaries to /opt...
66 Emery


Subject Author
Re: [gentoo-dev] dev-lang/go "Rick \\\"Zero_Chaos\\\" Farina" <zerochaos@g.o>
[gentoo-dev] Re: dev-lang/go Ryan Hill <dirtyepic@g.o>
Re: [gentoo-dev] dev-lang/go Alec Warner <antarus@g.o>
Re: [gentoo-dev] dev-lang/go yac <yac@g.o>