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 B7F97138E20 for ; Thu, 20 Feb 2014 00:52:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3D911E0B11; Thu, 20 Feb 2014 00:52:15 +0000 (UTC) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3DA9CE0B03 for ; Thu, 20 Feb 2014 00:52:14 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id l6so1380642oag.21 for ; Wed, 19 Feb 2014 16:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=JFEdyhR3Co17Ts63Nx+yd/knE+GDlG/t2ZE2l14IhEc=; b=gJAoyhsTKdOJmhTelwb/EgVbe8LfBRHtJVhtrqWOHhdFly7rG2KrwI87YKL+T87guX 86aI4Qf1B/Wdi9rHofLFELc74PKWI2B1OWXVTQKHT5bb8y/xnWyzaD4MD4hdB8z9ML2t 0u+/MkUJ3CzRGkkCHH8zHdE2qrPNQ6CYhsfD6RBtDLs9Z8NJXuC3osI/LsdkTPP5cFuc 3Q7nx5ZSaYnHqWdvnk4nz/tulVnNvpVGk8zloQL4JXmoKl0qvgRLeJtKGgeRGdYhBsWg AYkkK7c/DeLxgj+rPYMJS9Z9Hy57ieNeLTzuXDLSaY2KcdzPJzf2PFgCmjDXt/7U3S5P JLVQ== X-Received: by 10.60.134.166 with SMTP id pl6mr34168099oeb.16.1392857533377; Wed, 19 Feb 2014 16:52:13 -0800 (PST) Received: from laptop (cpe-76-187-91-128.tx.res.rr.com. [76.187.91.128]) by mx.google.com with ESMTPSA id o6sm12916254oel.4.2014.02.19.16.52.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Feb 2014 16:52:11 -0800 (PST) Sender: William Hubbs Received: by laptop (sSMTP sendmail emulation); Wed, 19 Feb 2014 18:52:34 -0600 Date: Wed, 19 Feb 2014 18:52:34 -0600 From: William Hubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] dev-lang/go Message-ID: <20140220005234.GA15616@laptop.home> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20131230154817.34a69433@ciguri> <20140211013844.4057ddb2@gentoo.org> <20140213175916.GA1919@laptop.home> <20140214133010.153a46b8@deathstar> <20140214110249.27842f70@ciguri> <20140215004844.49e9b7f2@gentoo.org> <20140215224409.GA1593@laptop.home> <20140219123422.702e5210@gentoo.org> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <20140219123422.702e5210@gentoo.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 2816871b-72cb-44dd-8dcd-e2f5a794c056 X-Archives-Hash: ce7f23035d445396c44c1645d9dbe9aa --envbJBWh7q8WU6mo Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 19, 2014 at 12:34:22PM +0100, yac wrote: > On Sat, 15 Feb 2014 16:44:09 -0600 > William Hubbs wrote: >=20 > > On Sat, Feb 15, 2014 at 12:48:44AM +0100, yac wrote: > > > On Fri, 14 Feb 2014 11:02:49 -0500 > > > Emery Hemingway wrote: > > > > The default GOROOT that go looks at for base libraries seems to be > > > > compiled in so this should be pretty easy, like python but > > > > simplier. > > >=20 > > > I'm not sure what you are trying to solve here. Afaik GOROOT is > > > used to determine where to install and it can be overriden from env. > >=20 > > Not overridden, but extended. See go help gopath. > >=20 > > > > An eclass could look at a GO_MINIMUM variable and install for each > > > > version go that is present and matches. > > >=20 > > > It might be good idea to learn from others who'd been through this > > > and I think the new python eclasses are good ones, going with > > > something like PYTHON_TARGETS array (GOLANG_TARGETS ?) > > =20 > > I would prefer go_targets if this becomes an issue, >=20 > golang is more search friendly >=20 > > but it isn't at > > this point because there is only one target, go1, and we do not know > > if there will be a go2 or not. >=20 > There still are different compilers at least, even if changing minor > version would be a non-issue. But I'm not familiar with those, I think > those are used for compiling for other than the supported archs (iirc > only x86 and x86_64) Also add arm to the supported list along with amd64/x86-fbsd. The only other compiler is gccgo [1], but it is part of the gcc toolchain, so I have no idea what they are doing there, or if our toolchain guys are even supporting it. Also, if you look at the comments on that page, it is a bit behind dev-lang/go. It is not clear to me either whether gccgo works on other architectures, and whether it is a compiler or a front end like the old cfront used to be for c++. Also, I don't know whether it will even share the same libraries as dev-lang/go; it may just use standard libraries stored in /usr/lib. In short, I have no clue how gccgo works. ;-) >=20 > > > > Dropping old versions of go > > > > will be easy because linking wont break, and new releases should > > > > be forwards compatible. > > >=20 > > > So far yes I think but I guess that may be quite different with in > > > the future with >1.x, and "should be" so there may be corner cases > > > where the user does need to use earlier version. > >=20 > > Highly unlikely in the context of go1, and again, we don't know if > > there is going to even be a go2 or not. The only reason there will be > > a go2 is if there needs to be a change at the source level which can > > only be done in a backward incompatible way. > >=20 > > The question really should be, do we want a system-wide workspace to > > store third-party libraries [1]? > > and if so, where do we put it -- maybe /usr/lib/go-gentoo should exist > > along side /usr/lib/go? >=20 > I assume you are talking about thirdparty packages installed by > portage, not by localy/manually by user. Well, without the system-wide > workspace to store the libraries, this whole go eclass would be kinda > pointless, no? >=20 > Currently /usr/lib/go/gentoo is used and I see no reason to change it. Well, I was suggesting go-gentoo to keep third party libraries out of the standard go tree and based on the definition of a workspace from the go documentation. > > The catch would be that every time you upgrade dev-lang/go, everything > > stored in /usr/lib/go-gentoo has to be recompiled because there is no > > guarantee that the libraries we have there are compatible with each > > minor release of go1, only the source. > >=20 > > Then, the executables we have in /usr/bin will still run, but it would > > be good to rebuild them as well to get the new libraries linked into > > them. > >=20 > > If we had a work space in, say, /usr/lib/go-gentoo, we could leave the > > executables in there and symlink them to /usr/bin. If we did that, it > > would be easy for a user to rebuild everything in the workspace for > > the new go by doing > >=20 > > emerge /usr/lib/go-gentoo/bin >=20 > Good idea. >=20 > > Thoughts? > >=20 > > William > >=20 > > [1] http://golang.org/doc/code.html >=20 >=20 >=20 > --- > Jan Mat=C4=9Bjka | Gentoo Developer > https://gentoo.org | Gentoo Linux > GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B [1] http://golang.org/doc/install/gccgo --envbJBWh7q8WU6mo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlMFUdIACgkQblQW9DDEZThJIACbBc4RinsnTNoExnHtxf4UMYeA 6qcAmgNuw/iIK7ItRif0KMhbR/zXf5zo =9fMl -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo--