Support for both linux/amd64 and linux/arm64 architectures when installing the Language Support for Ada extension in VS Code

[dalybrown]

Currently, when installing the extension in VS Code, regardless of your host architecture (e.g., linux/amd64 or linux/arm64), the extension installs the linux/amd64 version of the Ada Language Server.

I develop on a linux/arm64 architecture; therefore, I have to build the Ada Language Server myself for linux/arm64 and replace the version the extension installs.

It would be nice if both versions of the Ada Language Server are built (linux/amd64 and linux/arm64) and when installing the extension from within VS Code (or however you choose) it chooses the correct architecture.

[AnthonyLeonardoGracio]

I agree it would be great, we'll see what we can do

[dalybrown]

It seems like in the latest version of the extension, my work around of building the language server out of band for arm64 and replacing the version installed by the extension doesn't work anymore. It detects my architecture (arm64) and complains that it does not support this.

This seems like a further regression.

[eliericha]

Hello @dalybrown ,

In an effort to improve support for different platforms and OS-es we introduced more precise checks on the characteristics of the environment to produce better error messages on unsupported platforms.

However as you observed, this had the inadvertent effect of making it no longer possible to simply deposit the executable produced by other means at the right place and have things work.

We'll discuss and find a way to restore that functionality. Off the top of my head I can see 2 options:

1. Make the extension look up the available ada_language_server executables, and if one is found at the location matching the architecture and OS of the environment, then it should proceed with that one.
2. Inspect the ALS environment variable, either already in the environment, or configured within the terminal.integrated.env.(linux|windows|osx) setting. If ALS provides an executable file, then that should be attempted as the language server regardless of the detected architecture and platform.

I'm leaning towards option (2) which allows the executable to exist anywhere and not necessarily need to be copied into the extension.

[dalybrown]

Thanks!

Is there something fundamentally stopping you from just building the most common architectures (amd64 and arm64) and detecting / installing the correct one when installing the extension? I feel like that would better solve the problem for most users (not sure how native Mac M# would work, I use docker on my M1 hence the linux/arm64 architecture).

If the issue is just building the linux/arm64 version of the language server, I already do this in my private CI system. I can make it public and release it on GitHub or contribute it back so that both architectures are available.

[eliericha]

Hello there,

The problem has been fixed in the latest release of the extension 24.0.1. You can now set the ALS environment variable to the path of your custom build of the language server and the extension will use that.

The variable can be set in the environment prior to calling VS Code, or configured in the terminal.integrated.env.(linux|windows|osx) VS Code setting.

Let me know if that addresses your issue.

As for your other question, we don't currently distribute builds for the arm64 architecture because there are no arm64 runners readily available on GitHub yet. We try to distribute only from the GitHub infrastructure to make sure that anyone can reproduce those builds if they wanted to.

BTW it's possible to work directly on Mac M1, even though it's not officially supported. Currently on macOS, even on arm64, the extension uses the amd64 executable thanks to Rosetta. You may have to go through some security warnings but ultimately it works. And there are Ada toolchains available for macOS, I believe nowadays there's even an arm64 one. So if you want you could try working on the M1 directly, but it's not a very well supported platform.

[dalybrown]

Thanks!

I prefer working within a docker container anyways ... I'm able to have reproducible development environments for anyone working on the codebase.

I'll try out the updated environment variable and see how it works!

Regarding the build system, there are a few options available: you can build the ada language server within docker use a multi-arch docker build. This will use qemu for the arm64 build when building in your amd64 runners, but it will work. This is what I currently do to build the Ada Language Server (we use GitLab though ... but same idea). It will burn through your free minutes though.

Alternatively, you can use another service that has some free build minutes to build the arm64 version. Especially if you don't build it too often (i.e., only on releases). One example is here: https://depot.dev/. They have some free minutes, and have GitHub actions available to connect to your existing pipeline.

[dalybrown]

(I should mention the other reason I don't work directly on my mac but within a debian docker container is that I also build the libadalang tools (gnattest, gnatpp, etc.), gnatprove, and gnatcoverage for arm64. I believe those aren't available for Mac M#.)

p.s., it would be nice to also build all those tools for arm64 too so I don't have to maintain them myself :).

[eliericha]

Hello @dalybrown . The latest release of the VS Code extension now includes arm64 versions of ALS for linux and macOS. As this makes the VS Code extension package pretty heavy, we are also looking into getting the ALS downloaded after installation for the specific host architecture. But I believe that for the time being we can close this issue. Let us know if you encounter more issues.

[dalybrown]

Thanks! I've updated to it. Great job! (And yeah being able to selectively download the correct architecture would be great.)