On Wed, Sep 25, 2019 at 10:02:34PM +0200, Michał Górny wrote:
> On Tue, 2019-09-24 at 13:08 -0500, William Hubbs wrote:

*snip*

> > +# @DESCRIPTION:
> > +# This eclass provides basic settings and functions
> > +# needed by 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.
> 
> Hmm, don't we want to eventually have one eclass that fits all packages?
> I mean, if you can automatically determine whether modules are present
> via go.mod file, can't you just make one eclass that determines that
> and passes correct flags for both cases?

I hadn't thought about making one eclass for several reasons.

The primary reason is that go upstream is pushing toward all go devs
using modules, so ultimately building without using modules will be
unsupported.

The second reason is part of the API for a combined eclass would have to
be a global scope variable to tell the eclass whether or not to use
modules. The reason for this is src_unpack has to behave differently
based on whether or not the package uses modules.

Also, most of the machinery in the golang-* eclasses deals with
manipulating/using GOPATH which is completely irrelivent for modules.
golang-vcs-snapshot.eclass and golang-vcs.eclass are only needed if your
package is not using modules.

The tl;dr is that Go builds are becoming much simpler to deal with
because of go modules.

If you think there is functionality in the golang-* eclasses that is
generic enough to add to this eclass, let me know.

I'm about to send out a re-roll that I think covers your changes.

William