Build static executable for linux aarch64 #3866
Conversation
This has been EOL since November and has been dropped from nixpkgs.
Instead of rolling our own, we can use some tooling from nix / nixpkgs. We drop the "statically linked" check, because our goal is to compile mostly-static executables to darwin, too. However, those will never be fully static, because they always link to the platform's libc.
We have fixed the static build of PostgreSQL upstream, so we don't need our separate overlay anymore. One more step towards building a static executable on other platforms.
This way we benefit from NixOS' binary cache to deliver GHC for us and don't need to cache it ourselves. This will become relevant once we do that for more platforms.
While neat-interpolation builds fine in the static overlay, we still can't actually *use* it for cross-compilation. Every quasi quotation needs to execute Template Haskell during compilation, period. Thus, get rid of it. Currently, we keep heredoc for the test-suite. It would probably be a **huge** pain to remove all quasi quotation from the spec tests, so we don't even need to bother with that. As long as we can build the static executable we should be good.
Completely fine with that too.
Could we fork (or vendor) swagger2 and do the same process to get rid of the template haskell dependency? Looks like that would be the quickest way to unblock this. |
I'm not sure whether that would be faster. They do actually use Template Haskell there for code generation, I think - at least for me it would take quite some time to actually understand what they're doing. Plus, we'd end up with some dependencies which are not on hackage, again, which works against our goal of eventually having an up2date PostgREST available in nixpkgs itself as well. |
This is based on #3865, so the first few commits are from there.
Right now, this is a POC: What happens when we remove all the Template Haskell, update to GHC 9.6/9.8, and then try building the static aarch64 executable again?
This happens:
Once we have that, we could once more simplify our docker image and ship the minimal, single executable for both platforms. Drastically reduced size.
I also tried to build the static executable on aarch64-darwin and x86_64-freebsd. There's still a bit more work to do for those, but it looks much better than... a year ago. In any case, we need to do our part first.
In #3597 I introduced neat-interpolation as the quasi quoter, because it cross-compiles better. It does - but any project actually using it, will still have the same "external interpreter" problem that any Template Haskell causes. So the only way forward is to remove all use of Quasi Quoters. Yes - the change look a bit ugly, with all the quotes etc. - but that's the best we can do right now.
GHC 9.12 has native multiline strings, which could go a long way already. We're still a bit away from making 9.12 our minimum version, though. There's also a GHC proposal for native string interpolation, which would give us everything we need, once agreed on and implemented. But yeah - even further out in the future.
Let's see how long we need to replace OpenAPI - maybe native string interpolation is already widely supported by then ;).