Could zig be used to simplify cross compiling ddev?

[nickchomey]

I just came across these articles that show how zig can be used to seamlessly cross compile golang binaries from a single OS. I thought that perhaps it could be helpful to reduce the complexity (eg a closet full of servers) for ddev building, testing etc

https://dev.to/kristoff/zig-makes-go-cross-compilation-just-work-29ho
https://zig.news/kristoff/building-sqlite-with-cgo-for-every-os-4cic

And a pretty good summary from chatgpt
https://chatgpt.com/share/67d81b11-cf84-8009-97c9-f8166618baa9

I suspect this won't actually help, as ddev has an immense scope, but figured I'd share it.

[rfay]

Thanks for pointing this out. Go is really awesome with its built-in cross-compiling, which we use extensively and which works on every platform we've used. The problem as pointed out here is that with CGO_ENABLED=true it uses native-built c functions in some cases, and that ruins it all. For that reason we've made sure to avoid all uses of CGO_ENABLED=1 and not use any libraries that use it. If we got in trouble with some need like that we'd have to do something like zig. Lima did get in that trouble, and now uses CGO_ENABLED. I'm not sure how I'd trust zig in that situation though, since there's no obvious way to test.

We already build and sign the Windows binaries on native platform, because there's no way to sign them elsewhere (there used to be).

[nickchomey]

ah, I should have browsed the code more closely - I only searched for cgo, saw it in some files and created the discussion. Indeed, it seems to be set to false/0 where mentioned. Anyway, hopefully this is informative to some people