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. |
4 |
|
5 |
|
6 |
For those who aren't familiar with Go, I will sumarise why Portage and |
7 |
Go do not play well together. |
8 |
|
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. |
13 |
|
14 |
It is possible to compile dynamicly and that may involve using the |
15 |
GCC frontend, which is probably less tested and less optimized. |
16 |
|
17 |
|
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. |
26 |
|
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? |
30 |
|
31 |
|
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: |
35 |
http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=eclass |
36 |
http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=dev-go |
37 |
http://git.overlays.gentoo.org/gitweb/?p=user/emery.git;a=tree;f=net-p2p/btcd |
38 |
|
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. |
42 |
|
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. |
48 |
|
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. |
59 |
|
60 |
|
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... |
64 |
|
65 |
|
66 |
Emery |