Investigate building Wasp for more Linux architectures (i.e. ARM)

[sodic]

Currently (as of 0.13.2), we're releasing Wasp Linux builds only for Ubuntu x86. It works on most of the Linux distribution, but not all of them (e.g., Raspbian).

For users that don't run a compatible distribution, the only alternative is building Wasp from source source.

We should consider some of the other more popular targets (e.g., ARM) if these reports keep popping up.

Related: #1100

Users running into this:

• https://discord.com/channels/686873244791210014/1216022996020625458/1216022996020625458

[Martinsos]

I coudl bet we had an issue about making our compilation more static, but I can't find it -> that is also related. Right now it is not completely static, but quite static (with glibc being the main culprit).

[Martinsos]

For ARM, there was also a quite big discussion here: https://discord.com/channels/686873244791210014/943092165964349500/1149268438888501278 .

There are a couple of different things here though: one is building wasp CLI for ARM, and another is deploying an actualy Wasp app (server with its Dockerfile) to an ARM server. We might want to split this into multiple issues actually.

Some excerpts:

1
For deploying from an Arm system to an x86 server, this works fine for a few reasons. First, in the Wasp deploy to Fly.io case, it is fine because we default to remote building. So it will build on Fly infra and deploy there.

However, it also works just fine if you build locally on Arm and deploy to Fly (https://wasp-lang.dev/docs/advanced/deployment/cli#building-locally). In this case, it builds with this local context and still works fine.

In the general case, Arm can deploy to x86 via Docker because of the ability to do the note here: https://wasp-lang.dev/docs/advanced/deployment/manually#deploy-to-a-heroku-app e.g. --platform linux/amd64.

So it sounds like the main open question is can Wasp do a Docker build natively on Arm and/or deploy to Arm?

2
For building locally, indeed there is a lib-sodium error, but it appears the root cause is Python is not installed before running the npm commands. So you could change your base image to something with Python installed, or you can just move up the Python install line that is there somewhere earlier in the process.

exe: move this line https://github.com/wasp-lang/wasp/blob/main/waspc/data/Generator/templates/Dockerfile#L43

up somewhere higher up, like here:
FROM node AS base
RUN apk add --no-cache python3
[14:16]
with that change, my local build worked and it can start

3
Lastly, the native wasp CLI builds you already make work fine on Arm in a native, non-Rosetta terminal

https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment :
If an executable contains only Intel instructions, macOS automatically launches Rosetta and begins the translation process.

And actually building the Haskell stuff also worked fine on Arm for me in a native, non-Rosetta terminal (eventually) too. I originally installed it all through Rosetta, but after like 6 months I read support was good enough on our GHC version and retried using installs outside of a Rosetta terminal ghcup and it all seemed to work fine from my recollection. It may be because they are passing arch -x86_64 flags behind the scenes though, unsure.

OK, so if wasp CLI binary runs on ARM, then that is solved already -> the only thing left is fixing Dockerfile so it can build for ARM, right? And @shayne you said it is enough to just move python installation up, while @Zeko369 you suggested using node-slim.
What is our conclusion then? Maybe it is easiest to do node-slim so we ensure we have basic stuff installed and that is it?

So TLDR, install LLVM 13 from homebrew and export it and then you can build Wasp on Arm just fine 👍 Ping if that does not work for you @Zeko369 and sorry I didn't document, but I was previously the only one on M1 and I forgot that one tiny extra step that was required. Additionally, I am unsure if newer LLVM versions work or it has to be 13, but you can use that just to be safe if you want (which I would recommend).

TODOs:

1. node-alpine -> node-slim => faster build (40s -> 20s) + works on ARM
2. setup arm CI so we can deliver native ARM CLI binaries (or at least test that)

But I recommend reading the whole discussion!