Do not include binaries in the repo about nwg-drawer

[WhyNotHugo]

Committing the binary into version control is highly discouraged and unsustainable. The repository is over 140 megabytes, and will continue to grow at a huge pace indefinitely. It also took me 14 minutes to clone it, so the build-time benefits are arguable.

They are useful. Building gotk3 library on my laptop takes 15 minutes.

Running go build re-builds gotk3 (and everything else) again upon the next build anyway, so this really only helps someone cloning the repository with no intention of making any code changes. Sounds like what you want is to just publish artefacts.

It's easy to skip building, just by removing this step from PKGBUILD.

If your intent is to use the binaries for packages, you'd probably be better off using something like GitHub actions to build them and downloading those artefacts. I don't think you don't need to version-control each build and retain them indefinitely. Each build is 7MiB, so each time you commit a build the repository will grow by the amount each time (git doesn't really handle diffing binaries).

[nwg-piotr]

They are useful. Building gotk3 library on my laptop takes 15 minutes. It's easy to skip building, just by removing this step from PKGBUILD.

[nightly-brew]

I get it, and as a matter of facts it's useful when building locally, but the repo shouldn't track it.

In theory that ELF is intended for x86_64 systems, so what happens if I clone the repo as it is and try to build on an arm system?
Will go discard the already built binary or will it throw out errors and stop the build process?
I was taught that's one reason it's uncommon to maintain built binaries in the repo, but I may have been taught wrong.

For binary distribution, wouldn't it be better if the PKGBUILD pointed to binaries uploaded on the release page?

[nwg-piotr]

Probably. This was just a handy shortcut. Plus I didn't want to maintain separate -bin packages.