First glance on CLion (as a remote editor)

Last week we reviewed Visual Studio as a Windows-side IDE that runs and builds on remote Linux hosts. Today we will be looking at the very popular CLion. CLion is sold as a cross-platform C++ IDE. I have seen it been used on Linux but only being used as a local editor, ie user logs into Windows but remotes into a graphical Linux desktop using some sort of RDP like nomachine or tightvnc. That is slow and flimsy as connections are always dropping, there are windows resizing issues, the screen looks pixelated and so on. Native windows editors shine because they are snappy and responsive.

So far I have only seen Visual Studio Code used in this way and I have become a fan, to the point of dropping emacs. I have tried Visual Studio remote before but in the 2017 version it was quite disappointing.

CLion, in contrast, has had this feature for many years so I come to this test with a lot of expectations in mind. I point my browser to and I’m immediately informed that this is is a commercial offer with a 30-day trial.

After trial, it will cost you $9/month or $90/year with a multi-year discount.

CLion does not have a community version like Visual Studio

Hit download and wait for the 500MB to download. Once installing, I noticed CLion is a Java application which worries me since every Java interface I used (Eclipse anyone?) was unnervingly slow and glitchy.

Definitely a Java based offering

After an awkward process of authenticating with their website that took over 30 minutes to get through, I finally got into the IDE.

Checking out OpenCV from Github

Once you are in, CLion will notify that there are no toolchains configured and will provide a link. Once clicked, you have the ability to choose a remote host.

Adding a remote host toolchain to CLion IDE
Configuring the remote host is very easy and contains powerful options

After configured, CLion starts pushing the sources (rsync) into the remote host, which took an abnormally long time, perhaps because it prints out every file name it copies and there are thousands of them.

Once I hit menu Build/Build Project the process was smooth and went right away, finishing without problems.

Build finishing without any complaints or glitches
Adding a new cmake configuration

The cmake configuration seems to be simple and not quite as sophisticated as Visual Studio’s. Unfortunately things started to break down as I tried to set the build directory to my fast nvme drive mounted on /ssd.

Apparently this is an issue that has been known for more than a year and it still has not been resolved. From what I can see, it seems that CLion is processing the build directory option as the local Windows directory and passing the “window-ized” version of that name to the remote host. This shows that the remote capabilities are not quite well integrated yet. Not being able to set the build root directory on the remote host is quite a crippling bug to remain open for so long.

Another strange feature is that on CLion both the Debug and Release versions are built at the same time once you hit the build hotkey. For a small project that will be okay but for large projects that will be quite a waste of resources as most of the time a developer will be working with one or another build version, not both. To work with a single build version you’d have to go to settings and manually disable the other, which is not a big deal but sort of unintuitive, at least for me.

As for debugging, it took a bit to get used to how CLion sets up debugging but that would be normal for someone just starting with it. It was quite annoying though that there is no option to start debugging with a step instead of by explicitly setting a breakpoint on main.

Remote debugging in CLion is seamless

One big bummer was trying to add include files that are not in the standard paths. Say for example that you compiled your own libc++ and its headers are installed in /usr/local/include. CLion apparently always pick up the headers on /usr/include although it has been explicitly set in the cmake files. Visual Studio allow for additional directories to be provided to Intellisense but CLion seems to be struggling with this request since it was filed in 2014.

So although overall it seems that CLion is a very capable editor, it looks quite amateur if compared with Visual Studio, which shines as a more rounded offering. The fact that some basic settings bugs are still not solved after years of being reported, leaves me with a very bitter aftertaste in the mouth. Combined with an awkward licensing scheme and a $90/year bill, I think I’m going to stick with Visual Studio and VS Code for now.

I know CLion has many fans and given I’m a rookie with this editor, please let me know in the comments if you want anything in this article added or rectified.