Configuration to package shared libraries (so, dylib, dll)

[borgoat]

Hi!

I am building a Go library exporting a C interface. I've been trying to use goreleaser to package it and release it, partially with success, but I feel I'm still missing something. I'd like to gather all the pieces of info required, and possibly contribute some docs or other changes to the code that may help in such a scenario.

For reference, this is the latest configuration I could come up with: https://github.com/borgoat/farmfa/blob/d57c6497cd7b723c2ae15f063426ea84e140d48a/.goreleaser.yml#L13-L36

So far, I have faced these constraints:

• I did not manage to package the header (.h) file in the archive. This is generated by the go compiler, and correctly placed in the dist directory, next to the shared object. However, because it is only known at build time, using the files directive in the archives stanza is not working.
• I had to provide the binary name including the extension. Arguably this is not a big deal, but different OS use different conventions (.so on Linux, .dylib on macOS, .dll on Windows). This could also apply to static libraries. I did find issue feat: Add support for c-shared and c-archive build modes in windows #1243 adding support for the dll extension on Windows. Would it make sense to add something similar for other operating systems?
• I haven't looked at this in detail yet to be honest - but I'd like to also do a Web Assembly build too. Are the points above applicable in that case too, or maybe there's some exception here? I found feat: wasm support #1159 but not much in the docs.

[caarlos0]

I haven't heard of anyone using goreleaser to releaser shared libraries, so I'm sure there are things missing... both docs and possibly feature/config wise.

The file extensions and lack of .h file seems like a bug, yes.

We'll probably need to add an option to the build saying "build this as a library" and handle the files et al, as well as a lot of things that assume there's always a binary that would have to be skipped/changed.

Do you have interest in working on any of that? Otherwise I can give it a try, but would probably need some support... btw, if you prefer a faster feedback et al, discord

[borgoat]

Yes, I agree that it is not a common use case. A quick search on GitHub did not yield many results... anyway, I greatly appreciate the GoReleaser workflow, and it'd be very convenient for me to have this additional feature to close the loop. If you agree that it would be valuable to implement, I'd be happy to contribute it!

[caarlos0]

I think it should be a relatively small change, so I we can probably add it, yes

happy to review what you come up with :D

[caarlos0]

This is now improved (merged into master, #3511, thanks @borgoat <3)

Will be released in v1.13 very soon!

[borgoat]

Awesome! Thank you for the support!