Re: ALTERNATIVES framework and multiple package versions question

[Bartek Krawczyk <bbartlomiej.mail%gmail.com@localhost>]

On Sun, 6 Dec 2020 at 10:16, nia <nia%netbsd.org@localhost> wrote:
>
> On Sun, Dec 06, 2020 at 10:07:00AM +0100, Bartek Krawczyk wrote:
> > Thanks.
> > Do you or anybody else have suggestions to my other questions? How in
> > reality such situations should be handled where source Makefile uses
> > "go" binary but we provide "go115"?
>
> Generally speaking, replace the executable name with the SUBST
> framework using the variable GOVERSSUFFIX defined in
> lang/go/version.mk.
>
> But this might not be the best solution, since go packages
> are generally handled by lang/go/go-package.mk. Maybe the
> Makefile shouldn't be used...?

Thx nia, I may have not been clear enough. I am working on packaging
AdGuard Home which uses Go to build its binary (it compiles nicely on
9.1 using pkgsrc-2020Q3, no patching needed). It's not a Go module.
So AdGuard's Makefile (GNU make) has things like:

build: client_with_deps
        go mod download
        PATH=$(GOPATH)/bin:$(PATH) go generate ./...
        CGO_ENABLED=0 go build -ldflags="-s -w -X
main.version=$(VERSION) -X main.channel=$(CHANNEL) -X
main.goarm=$(GOARM)"
        PATH=$(GOPATH)/bin:$(PATH) packr clean

And I am wondering what is the "pkgsrc way" of building it:
- should it be corrected with SUBST framework?
- is allowing "go mod download" a good idea during package build? Or
should pkgsrc Go modules be used?

Thanks in advance.
-- 
Bartek Krawczyk