Created attachment 234785 [details] gohugo-0.101.0_1.diff Builds fine in poudriere 130a, 130i, 123a.
Thanks for this, Dmitri! Just downloaded and tested my end and it's looking good.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=93d16c5a5bea0be5d12b35b778a2615e47151009 commit 93d16c5a5bea0be5d12b35b778a2615e47151009 Author: Dmitri Goutnik <dmgk@FreeBSD.org> AuthorDate: 2022-06-19 15:08:08 +0000 Commit: Dmitri Goutnik <dmgk@FreeBSD.org> CommitDate: 2022-06-19 15:08:08 +0000 www/gohugo: Switch to GO_MODULE PR: 264770 Approved by: Ben Lavery-Griffiths <ben@lavery-griffiths.com> (maintainer) www/gohugo/Makefile | 150 +------------ www/gohugo/distinfo | 236 +-------------------- ...ep_golibsass_internal_libsass_a____cgo.go (new) | 15 ++ 3 files changed, 28 insertions(+), 373 deletions(-)
Just for the record, the webp dependency is an unfortunate step backwards. The port now needs webp, nasm, jbigkit, jpeg-turbo, tiff, and giflib just to transpile SCSS into CSS, not to mention everything required to build those deps. Is it possible to separate the webp build option from SCSS? It looks like upstream links them together, but my go-fu is pretty superficial. I use SCSS, but I don't need 6 image libraries.
(In reply to Adam Weinberger from comment #3) Looking at the upstream code, it doesn't seem like WEBP support can be toggled independently of SCSS, it's either both or neither (controlled by the "-tag extended" build flag). The WEBP support was already there in the previous version (when building with EXTENDED), the only difference is that pre-GO_MODULE version used bundled libsass and libwebp C++ sources and linked statically while modules version uses ports and dynamic linking, hence the need for nasm and the image libraries. I don't know how flexible our graphics/webp is, but perhaps knobs can be added to make support for various image formats configurable. I'll leave to the maintainer to decide how to better proceed with this, but I think the best solution would be to persuade the upstream to use more granular build tags instead of the blanket "extended", so SCSS and WEBP support can be toggled independently.
(In reply to Dmitri Goutnik from comment #4) Thanks for looking into it, Dmitri! I suspected that was the case... it seemed pretty tightly bound. I took your advice and looked into the WebP codebase, and you were right on the money there. The other graphics libraries are just used for some command-line image conversion tools. I submitted bug #264798 to put those deps behind an option.