tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ALTERNATIVES framework and multiple package versions question

On Sun, 6 Dec 2020 at 10:16, nia <> 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/
> But this might not be the best solution, since go packages
> are generally handled by lang/go/ 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$(CHANNEL) -X
        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

Home | Main Index | Thread Index | Old Index