public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: William Hubbs <williamh@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: mgorny@gentoo.org
Subject: Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: new eclass for go modules
Date: Wed, 25 Sep 2019 19:21:16 -0500	[thread overview]
Message-ID: <20190926002116.GA4964@whubbs1.dev.av1.gaikai.org> (raw)
In-Reply-To: <0cc7941079ba4ec9149f2a76b0a1bfd20649304e.camel@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 1849 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

      reply	other threads:[~2019-09-26  0:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-24 18:08 [gentoo-dev] [PATCH 0/1] new eclass for go modules (another proposal) William Hubbs
2019-09-24 18:08 ` [gentoo-dev] [PATCH 1/1] go-module.eclass: new eclass for go modules William Hubbs
2019-09-25 20:02   ` Michał Górny
2019-09-26  0:21     ` William Hubbs [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190926002116.GA4964@whubbs1.dev.av1.gaikai.org \
    --to=williamh@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=mgorny@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox