Gentoo Archives: gentoo-dev

From: William Hubbs <williamh@g.o>
To: gentoo-dev@l.g.o
Cc: antarus@g.o
Subject: Re: [gentoo-dev] [PATCH 1/3] go-module.eclass: introduce new eclass to handle go modules
Date: Thu, 12 Sep 2019 00:05:34
Message-Id: 20190912000525.GB21591@whubbs1.dev.av1.gaikai.org
In Reply to: Re: [gentoo-dev] [PATCH 1/3] go-module.eclass: introduce new eclass to handle go modules by Alec Warner
On Wed, Sep 11, 2019 at 04:31:00PM -0700, Alec Warner wrote:
> On Wed, Sep 11, 2019 at 10:28 AM William Hubbs <williamh@g.o> wrote: > > > Copyright: Sony Interactive Entertainment Inc. > > Signed-off-by: William Hubbs <williamh@g.o> > > --- > > eclass/go-module.eclass | 76 +++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 76 insertions(+) > > create mode 100644 eclass/go-module.eclass > > > > diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass > > new file mode 100644 > > index 00000000000..7009fcd3beb > > --- /dev/null > > +++ b/eclass/go-module.eclass > > @@ -0,0 +1,76 @@ > > +# Copyright 1999-2015 Gentoo Foundation > > +# Distributed under the terms of the GNU General Public License v2 > > + > > +# @ECLASS: go-module.eclass > > +# @MAINTAINER: > > +# William Hubbs <williamh@g.o> > > +# @SUPPORTED_EAPIS: 7 > > +# @BLURB: basic eclass for building software written in the go > > +# programming language that uses go modules. > > +# @DESCRIPTION: > > +# This eclass provides a convenience src_prepare() phase and some basic > > +# settings needed for all software written in the go programming > > +# language that uses go modules. > > +# > > +# You will know the software you are packaging uses modules because > > +# it will have files named go.sum and go.mod in its top-level source > > +# directory. If it does not have these files, use the golang-* eclasses. > > +# > > +# If the software you are packaging uses modules, the next question is > > +# whether it has a directory named "vendor" at the top-level of the > > source tree. > > +# > > +# If it doesn't, you need to create a tarball of what would be in the > > +# vendor directory and mirror it locally. This is done with the > > +# following commands if upstream is using a git repository: > > +# > > +# @CODE: > > +# > > +# $ cd /my/clone/of/upstream > > +# $ git checkout <release> > > +# $ go mod vendor > > +# $ tar cvf project-version-vendor.tar.gz vendor > > +# > > +# @CODE: > > +# > > +# Other than this, all you need to do is inherit this eclass then > > +# make sure the exported src_prepare function is run. > > + > > +case ${EAPI:-0} in > > + 7) ;; > > + *) die "${ECLASS} API in EAPI ${EAPI} not yet established." > > +esac > > + > > +if [[ -z ${_GO_MODULE} ]]; then > > + > > +_GO_MODULE=1 > > + > > +BDEPEND=">=dev-lang/go-1.12" > > + > > +# Do not download dependencies from the internet > > +# make build output verbose by default > > +export GOFLAGS="-mod=vendor -v -x" > > + > > +# Do not complain about CFLAGS etc since go projects do not use them. > > +QA_FLAGS_IGNORED='.*' > > + > > +# Upstream does not support stripping go packages > > +RESTRICT="strip" > > > > https://golang.org/cmd/link/ implies you can pass -s -w to the compiler to > reduce binary size. > > Does that not work in portage by default, or does upstream just consider > that bad practice?
I haven't tried it, but here are the definitions of -s and -w. -s Omit the symbol table and debug information. -w Omit the DWARF symbol table. These look like Go's equivalent of stripping the binaries, and I have my doubts as to whether we should force this. William

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies