installing visual studio code on debian buster and the raspberry pi 4 model b rev 1.4

A long winded title to announce that I’ve managed to create a deb file from Visual Studio Code source, and to install it on the Raspberry Pi 4 8GiB running Debian Buster 64-bit compiled for arm64.

The deb file was built on the Jetson Xavier NX board, then copied to a thumb drive, then moved over via the thumb drive over to the Rasbperry Pi and installed from there. So far it’s behaved reasonably well. I’ve learned quite a bit about the build tools that come with the source. I suppose it’s good that I found some of the directions I did on the web, but now that I’ve gone through this whole process a number of times, what I used to start with short circuits what is available in the source tree cloned from GitHub.

I appreciate that I can use the Jetson NX as a build system. I also appreciate that there is a method in the source tree for building the deb file. That to me is super. Now I can keep up with releases, knowing I can target 64-bit ARM binaries for Debian/Ubuntu.

And speaking of Debian, the 64-bit OS running on the Raspberry Pi now identifies itself simply as Debian.

Once I feel comfortable running the full build suite in Visual Studio Code I’ll post a streamlined how-to for ARMv8/aarch64/arm64. Too many labels, frankly.

successfully building a working visual studio code on the jetson xavier nx

In two earlier posts I wrote about building Visual Studio Code (vscode) so I could use it for development on the Jetson Nano and NX. I thought my build was a failure. Turns out, it wasn’t. What was a failure was my ability to understand how certain aspects of vscode have come to operate over the last few major releases. Once I really sat down and paid attention to what was happening, everything just fell into place.

As before I used the directions on Clarence’s Wicked Mind blog ( ). Even though these directions are now over a year old, they still work, which to me is amazing considering how bit rot can quickly set into any given how-to. Since I’m still building off trunk, and not the latest formal release, I wound up with this version:

The current formal release is 1.46 (I checked on my Mac).

I went in and picked out the extensions I wanted to work with because of what I’m working with on the NX:

And for the curious, I’m running the Docker extension with Docker on the NX, and just for grins, I opened up the debug console on the right, just to see what that was all about. All pretty impressive and it looked really interesting, except for the Recommended section on the bottom left, which is empty. And that’s what kept sending me over into the weeds.

I could have sworn on a stack of Bibles that Recommended is never empty. So I went and checked again on my Mac, and wouldn’t you know it, it only had two entries. The behavior I’m describing used to be this way, on Windows. But it changed, and even though I’ve been good to keep up with the updates, I just didn’t pay attention. So when I saw zero recommendation I thought it was somehow broken. Until I went searching for something, and discovered this behavior all over again:

When I searched for ‘angular’ as an example, lo and behold I got all the Angular plugins. A few more searches and I was finally convinced I had a fully working VSCode for the Jetson SBCs. I was just absolutely stupid.

And since I started out with Docker, here’s a bit more of the Docker plugin to gaze upon:

The Docker plugin gives a bit more control and insite into Docker containers. The middle upper window is latest.json for the image, while the bottom middle is attached to the bash shell running inside the container. The right window is the debug window for all of VSCode, just so it looks cool in the blog post. Whatever…

Right now I’ve got a fully operational instance of VSCode by following someone else’s directions to build it. And I couldn’t be happier. Hopefully, I’ve gotten past this patch of personal stupids. But you never know.