From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 46228138247 for ; Wed, 1 Jan 2014 06:51:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A2117E0AD5; Wed, 1 Jan 2014 06:51:08 +0000 (UTC) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 76127E0ACB for ; Wed, 1 Jan 2014 06:51:07 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id bz8so13037610wib.17 for ; Tue, 31 Dec 2013 22:51:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=CWAUPMfPs/2+xtsIemJH9r87LYL5GCmHQyrxO/dPzUc=; b=DQ/ZknTn2gXTmeZDlPXP/bod7UsS7bb0TdEPL1EQS/JgbP99CBMQMKIWY/Pfwnhqjs EG4HitYuHmM61eiAiIbYo0mKxoXDsSEEQVSv4XaH0ynKGQxThtb9x7IiWiPxK7UpvR/N /pc2NsjKylb59OkcUiQujXWlaFJyErNlQryYz9GYIQ9jnoTiLrS/RRtrVRJ2cPZgP5wL Pq1GrXACAmUIH0tU21SVrKcF+UA5fdPtCm9Y2YV/tzTdAoPTSIoqDN33QKLtfTdfI5/o cU56nP1Oy5O+ulSyIlsCKONnSkYJNhSyNV4KZOojESzT+4vORq258TYTmSwsn316R5P3 4/ww== X-Gm-Message-State: ALoCoQljUDt1FzaiM4CcXOVFh21GpG0k9nJT4fgwAisr7qYm7tG+RYMg7rkyB+jf2cVnU7FBLIc6 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.180.19.165 with SMTP id g5mr49558548wie.31.1388559065848; Tue, 31 Dec 2013 22:51:05 -0800 (PST) Sender: antarus@scriptkitty.com Received: by 10.216.170.129 with HTTP; Tue, 31 Dec 2013 22:51:05 -0800 (PST) X-Originating-IP: [208.54.39.179] In-Reply-To: <20131230154817.34a69433@ciguri> References: <20131230154817.34a69433@ciguri> Date: Tue, 31 Dec 2013 22:51:05 -0800 X-Google-Sender-Auth: uxKIvZ7nyB6pB-YnpAHTUwgV9oA Message-ID: Subject: Re: [gentoo-dev] dev-lang/go From: Alec Warner To: Gentoo Dev Content-Type: multipart/alternative; boundary=bcaec53d5281deb5e904eee319ea X-Archives-Salt: eb82ce97-8154-46cc-8abc-e31c1a097aec X-Archives-Hash: c7139598815b3a5df0833205489803a9 --bcaec53d5281deb5e904eee319ea Content-Type: text/plain; charset=UTF-8 On Mon, Dec 30, 2013 at 12: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. > > 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 > > --bcaec53d5281deb5e904eee319ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Dec 30, 2013 at 12:48 PM, Emery Hemingway <emery@vfemail.net&g= t; wrote:
I really like working with Go, and would lik= e 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<= br> 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= =3Duser/emery.git;a=3Dtree;f=3Declass
http://git.overlays.gentoo.org/gitweb/?p= =3Duser/emery.git;a=3Dtree;f=3Ddev-go
http://git.overlays.gentoo.org/gitwe= b/?p=3Duser/emery.git;a=3Dtree;f=3Dnet-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 pe= rl and g-cpan?
=C2=A0
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<= br> anyway.

Can we version the shared objec= ts in the golang they were compiled for?

/usr/lib/= go/gentoo/GO_TOOLCHAIN_VERSION/...
=C2=A0

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 'he= y i want to move some libraries into /var/cache..cause you know...we can de= lete the libraries at any time...and we can just recompile them!'
=C2=A0


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


--bcaec53d5281deb5e904eee319ea--