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 123801387B1 for ; Mon, 30 Dec 2013 20:48:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DEF15E0B9B; Mon, 30 Dec 2013 20:48:27 +0000 (UTC) Received: from smtp102-3.vfemail.net (three.vfemail.net [108.76.175.3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id F02D2E0A9E for ; Mon, 30 Dec 2013 20:48:26 +0000 (UTC) Received: (qmail 16406 invoked by uid 89); 30 Dec 2013 20:48:26 -0000 Received: by simscan 1.4.0 ppid: 16396, pid: 16400, t: 0.2496s scanners:none Received: from unknown (HELO ciguri) (ZW1lcnlAdmZlbWFpbC5uZXQ=@MTYyLjE5Ny43MC4xNzE=) by mail.vfemail.net with ESMTPA; 30 Dec 2013 20:48:25 -0000 Date: Mon, 30 Dec 2013 15:48:17 -0500 From: Emery Hemingway To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] dev-lang/go Message-ID: <20131230154817.34a69433@ciguri> X-Mailer: Claws Mail 3.9.2-dirty (GTK+ 2.24.22; x86_64-pc-linux-gnu) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: a15f0317-2bd1-44db-876f-69309a0778aa X-Archives-Hash: 54512c48d8d90c0d048a9059bd5d2397 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. 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