1 |
On Fri, Feb 14, 2014 at 11:02:49AM -0500, Emery Hemingway wrote: |
2 |
> On Fri, 14 Feb 2014 13:30:10 +0100 |
3 |
> Jan Matejka <yac@g.o> wrote: |
4 |
> |
5 |
> > On Thu, 13 Feb 2014 11:59:16 -0600 |
6 |
> > William Hubbs <williamh@g.o> wrote: |
7 |
> > |
8 |
> > > Hi all, |
9 |
> > > |
10 |
> > > I responded to this a while back, but I guess my email didn't go out |
11 |
> > > for some reason. |
12 |
> > > |
13 |
> > > As the primary go maintainer, I do want to be involved in this. :-) |
14 |
> > > |
15 |
> > > On Tue, Feb 11, 2014 at 01:38:44AM +0100, yac wrote: |
16 |
> > > > On Mon, 30 Dec 2013 15:48:17 -0500 |
17 |
> > > > Emery Hemingway <emery@×××××××.net> wrote: |
18 |
> > > > |
19 |
> > > > > I really like working with Go, and would like to see a means of |
20 |
> > > > > merging Go packages with Portage. In short I am asking if anyone |
21 |
> > > > > else is interested in a Go project. |
22 |
> > > > |
23 |
> > > > I might be. I have packaged something for private use but it just |
24 |
> > > > a bunch of hacks. Anyway, I have some production go code. |
25 |
> > > > |
26 |
> > > > > |
27 |
> > > > > For those who aren't familiar with Go, I will sumarise why |
28 |
> > > > > Portage and Go do not play well together. |
29 |
> > > > > |
30 |
> > > > > Go is static linked by default. |
31 |
> > > > > The Go compiler creates static libraries and binaries. Libraries |
32 |
> > > > > compilied with different versions of Go (1.1/1.2) may not be |
33 |
> > > > > linked into the same binary. |
34 |
> > > > |
35 |
> > > > Haskell is staticaly linked as well (by default) and you can see |
36 |
> > > > the gentoo haskell project. I don't see this as a problem, we |
37 |
> > > > just will have all dependencies in DEPEND and will have to scope |
38 |
> > > > on the go compiler version under something |
39 |
> > > > like /usr/lib/go-1.{1,2}/... |
40 |
> > > |
41 |
> > > That could be done easily enough, but what about the tools |
42 |
> > > in /usr/bin (there aren't many, but there are a couple), and these |
43 |
> > > do not change name with each version of go. |
44 |
> > |
45 |
> > Please see what python does for different python versions (which you |
46 |
> > omitted from my previous email). |
47 |
|
48 |
I omitted it, because thinking about it, we don't need to worry about |
49 |
this. There isn't a reason you would want go 1.1 and go 1.2 on your |
50 |
system. Source level compatibility is guaranteed for all go1 programs |
51 |
[1]. |
52 |
|
53 |
> I've modified the go-1.2 ebuild to install to usr/lib/go1.2 and I'm |
54 |
> working on an eselect module to manage the symlink to usr/bin/[go,gofmt] |
55 |
|
56 |
I would just install to /usr/lib/go1 and not worry about the eselect |
57 |
module; there should not be a need to keep several versions of go1 |
58 |
around, again, because go1.x releases will be source compatible. |
59 |
|
60 |
We could even just leave this as /usr/lib/go, because upstream doesn't |
61 |
even know if a go-2 specification will happen. |
62 |
|
63 |
> The default GOROOT that go looks at for base libraries seems to be |
64 |
> compiled in so this should be pretty easy, like python but simplier. |
65 |
|
66 |
It looks for standard libraries in GOROOT_FINAL which is set in the |
67 |
ebuild and compiled into the binaries. |
68 |
|
69 |
Third party libraries are interesting in this case, because, all of the |
70 |
third party libraries we install will not be usable once the user |
71 |
upgrades from say go-1.2 to go-1.3. However, rebuilding those libraries |
72 |
from source will work. |
73 |
|
74 |
William |
75 |
|
76 |
[1] http://golang.org/doc/go1compat |