W dniu 06.12.2020 o 21:40, Bartek Krawczyk pisze:
Thank you all! It will be arriving - hopefully - this week in pkgsrc-wip. On Sun, 6 Dec 2020 at 16:47, Benny Siegert <bsiegert%gmail.com@localhost> wrote:On Sun, Dec 6, 2020 at 12:01 PM nia <nia%netbsd.org@localhost> wrote: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?It still looks like it's a go program, so it should use the pkgsrc way to build Go programs and probably not this custom thing? Yeh, packages shouldn't download files during the build process, they should all be in distfiles. I think we're moving away from having go modules in pkgsrc itself and intead using GO_MODULE_FILES.We have lang/go/go-module.mk for module-based builds. You can do the following: make show-go-modules > go-modules.mk and include that file in your Makefile. Then "make makesum" will make sure all the module files are present and fetched as part of "make fetch". Note that go-module.mk sets up a number of flags and variables so that the build actually uses the downloaded module files. So you will need to fiddle a little bit with the Makefile so that it does that too, and patch out the "go mod download" line. Good luck!
Hi all,I have commited some initial work on adguardhome package to pkgsrc-wip. So far it builds but I still have some problems and I need some feedback and hints.
Based on www/gitea I also added a phase to generate static frontend files in generate-frontend phase. This uses nodejs + npm to download dozens of packages. As www/gitea also described this would bypass pkgsrc fetch phase, hence the split.
- how may I get this archive uploaded to MASTER_SITE_LOCAL? Currently it is hosted on my temporary web server for testing purpose.
As suggested I tried to simplify the build process and ignored project's GNU Makefile completely. I tried to replicate their build process by overriding do-build target. This works fine.
Unfortunately AdGuard Home uses go:generate stanzas: //go:generate go install -v github.com/gobuffalo/packr/packr //go:generate packr clean //go:generate packr -zAs I understand it installs packr which also bypasses pkgsrc fetch phase and I am wondering how to work around this. (PREPEND_PATH you see will be removed once I figure this out. It is for testing to have packr available for go:generate).
I tried to add another wip/go-packr package and use ../../lang/go-package.mk for its installation but haven't been able to wrap my head around it so far. Since I am no Go developer I've been reading a lot and checked the source code of github.com/gobuffalo/packr/packr. Source files also have quite som import() declarations referencing other remote packages.
- how do you work around something like that? Is go-package.mk supposed to also take care of all external imports? Should a go-${package} be created for each such import first?
If packr was installed as build dependency this could be patched to remove the 1st go:generate line and leave following two as is.
On the positive side: AdGuard Home builds and _runs_ just fine. You can have a filtering DNS server. An alternative to pi-hole. On the negative side: I noticed beta versions of AdGuard Home already changed the build proces...
Does anybody have hints on how to move forward? Once the build process is ironed out I will of course take care of creating users, setting directories, permissions, installing start scripts etc.
Probably it is my lack of understanding on the Go build process, but having multiple places to import external resources (go.mod, go:generate, import() ) is nice for the developer but a nightmare to control and maintain.
Regards, -- Bartek Krawczyk