On Wed, Sep 11, 2019 at 5:05 PM William Hubbs <williamh@gentoo.org> wrote:

> 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@gentoo.org>
> wrote:
> >
> > > Copyright: Sony Interactive Entertainment Inc.
> > > Signed-off-by: William Hubbs <williamh@gentoo.org>
> > > ---
> > >  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@gentoo.org>
> > > +# @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.
>

I don't care if you strip or not (I'm not even sure portage knows how to do
it for go binaries) but I'm fairly sure the reason isn't because "upstream
does not support stripping go binaries" because they clearly do...unless
upstream is portage here...?


>
> William
>
>