graphics/gowall: Update 0.2.3 => 0.2.4

[nxjoseph]

Summary

Hi,

I am updating my port gowall to latest version.

I have tested runtime and the patch in Poudriere (14.3-RELEASE-p9, amd64, main(71e41147e4cb)) and it seems OK.

Thanks in advance.

graphics/gowall: Update 0.2.3 => 0.2.4

Changelog:
https://github.com/Achno/gowall/releases/tag/v0.2.4

Port changes:
* Add new option for new feature:
    - Background removal with AI (requires misc/onnxruntime)
* Refactor patching.
* Pet portclippy and portfmt.

MFH:    2026Q2

[osa]

graphics/gowall/Makefile

45

That needs to be improved, probably with !=. But it's unclear to me - does it really matter?

[nxjoseph]

Hi Sergey,

Thank you for your interest.

--- config/constants.go.orig    2026-04-10 19:26:33 UTC
+++ config/constants.go
@@ -15,7 +15,7 @@ const (
        UpscalerBinaryName = "realesrgan-ncnn-vulkan"
        PngquantBinaryName = "pngquant"
        EnvFilePath        = ".gowall/.env"
-       OnnxRuntimeVersion = "1.24.4"
+       OnnxRuntimeVersion = "%%ONNX_VERSION%%"
 )

 var (

This code needs to be patched, since it searches for libonnxruntime.so.${VERSION} and this version needs to be in-sync with port version. Currently we have onnxruntime-1.23.

Maybe I can remove the version-checking code and just make it search for "libonnxruntime.so".

/usr/local/lib/libonnxruntime.so
/usr/local/lib/libonnxruntime.so.1
/usr/local/lib/libonnxruntime.so.1.23.2

Thanks for your suggestion but I didn't understand it.

[nxjoseph]

Adjusted code, tested, and we don't need to know about version now. Thanks.

      case "freebsd":
-+              return fmt.Sprintf("libonnxruntime.so.%s", onnxRuntimeVersion)
++              return fmt.Sprintf("libonnxruntime.so")

[osa]

graphics/gowall/Makefile

45

As far as I understood that statement runs the ${MAKE} -C ${PORTSDIR}/misc/onnxruntime -V DISTVERSION command, gets an output, and then assign the output to the _ONNX_VERSION variable.

Please confirm.

[nxjoseph]

I have took reference from port www/iridium.

$ grep ESBUILD ../../www/iridium/Makefile
                evanw:esbuild:v${_ESBUILD_VERSION:sh}:esbuild/esbuild
_ESBUILD_VERSION=       ${MAKE} -C ${PORTSDIR}/devel/esbuild -V DISTVERSION

$ make -V _ESBUILD_VERSION
make -C /home/yusuf/doc/git/ports/devel/esbuild -V DISTVERSION

$ make -V _ESBUILD_VERSION:sh
0.27.1

Just defining _NAME_VERSION doesn't just do what you say, actually adding ":sh" makes it work, i didn't notice it first time too :D

man 1 make:

:sh  The value is run as a command, and the output becomes the new value.

[osa]

In D56348#1289483, @nxjoseph wrote:

I have took reference from port www/iridium.

$ grep ESBUILD ../../www/iridium/Makefile
                evanw:esbuild:v${_ESBUILD_VERSION:sh}:esbuild/esbuild
_ESBUILD_VERSION=       ${MAKE} -C ${PORTSDIR}/devel/esbuild -V DISTVERSION

$ make -V _ESBUILD_VERSION
make -C /home/yusuf/doc/git/ports/devel/esbuild -V DISTVERSION

$ make -V _ESBUILD_VERSION:sh
0.27.1

Just defining _NAME_VERSION doesn't just do what you say, actually adding ":sh" makes it work, i didn't notice it first time too :D

man 1 make:

:sh  The value is run as a command, and the output becomes the new value.

That's right. But, make(1) also has the following statement in the Variable assignment operators section:

!=      Expand the value and pass it to the shell for execution, then
        assign the output from the child's standard output to the
        variable.  Any newlines in the result are replaced with spaces.

Two recommendations:

1. In case a port needs to in sync with another one, let's follow that
2. In case this port needs a VERSION of another one, let's avoid using != assignment, instead let's create a version.mk file in the port-dependency (i.e.: misc/onnxruntime/version.mk), and then include that file with a version in this port.

[nxjoseph]

In D56348#1289488, @osa wrote:

In D56348#1289483, @nxjoseph wrote:

I have took reference from port www/iridium.

$ grep ESBUILD ../../www/iridium/Makefile
                evanw:esbuild:v${_ESBUILD_VERSION:sh}:esbuild/esbuild
_ESBUILD_VERSION=       ${MAKE} -C ${PORTSDIR}/devel/esbuild -V DISTVERSION

$ make -V _ESBUILD_VERSION
make -C /home/yusuf/doc/git/ports/devel/esbuild -V DISTVERSION

$ make -V _ESBUILD_VERSION:sh
0.27.1

Just defining _NAME_VERSION doesn't just do what you say, actually adding ":sh" makes it work, i didn't notice it first time too :D

man 1 make:

:sh  The value is run as a command, and the output becomes the new value.

That's right. But, make(1) also has the following statement in the Variable assignment operators section:

!=      Expand the value and pass it to the shell for execution, then
        assign the output from the child's standard output to the
        variable.  Any newlines in the result are replaced with spaces.

Oh, I didn't know about that "!=" in make(1), sorry. I thought it is meant for "if not, not equal". 😅

Two recommendations:

1. In case a port needs to in sync with another one, let's follow that
2. In case this port needs a VERSION of another one, let's avoid using != assignment, instead let's create a version.mk file in the port-dependency (i.e.: misc/onnxruntime/version.mk), and then include that file with a version in this port.

I think my patch that gets rid of the code that checks library based on version is a simple solution for this case.

[osa]

In D56348#1289489, @nxjoseph wrote:

I think my patch that gets rid of the code that checks library based on version is a simple solution for this case.

Well, follow that I have a couple of questions:

1. how those changes can be tested to get a confirmation all's working well after such change?
2. are you on position to share this patch with the vendor to get a confirmation that's OK, so the vendor can add your patch to the upstream.

[nxjoseph]

In D56348#1289495, @osa wrote:

In D56348#1289489, @nxjoseph wrote:

I think my patch that gets rid of the code that checks library based on version is a simple solution for this case.

Well, follow that I have a couple of questions:

1. how those changes can be tested to get a confirmation all's working well after such change?

I have tested it myself on my machine.

1. are you on position to share this patch with the vendor to get a confirmation that's OK, so the vendor can add your patch to the upstream.

No, since i don't prefer using GitHub and upstream maintainer hid their e-mail on git commits, too.

Thanks.