Webinar Recording: Remote Development with CLion

The recording of our February 28th webinar with Phil Nash is now available on the JetBrainsTV YouTube channel.

In this webinar, we took a look at some of the remote development topologies that developers work with, explaining how CLion supports them.

The video includes the time stamps:
01:06 – Intro with all the topologies briefly explained
07:53 – Remote GDB debug sample
11:30 – Remote GDB debug configuration
15:37 – Raspberry Pi demo: remote GDB debug
21:21 – Full Remote Development
26:00 – Raspberry Pi demo: full remote mode
29:50 – WSL case
32:30 – Q&A

Useful links and further reading:

Q: What if the remote is a Docker container? Can this be handled somehow similar?
A: While you can work with Docker containers as with regular remote machines now (so the Full Remote mode will work), you might be asking about smarter support, which includes Docker toolchains and some easy configuration steps (like we have for WSL now). The latest is not yet available in CLion, but we definitely have some plans for the future – see CPP-13751.

Q: What are the supported combinations of platforms for the Full Remote Mode?
A: The local client machine can be macOS, Linux, or Windows, but the remote host should be Linux. The setup is also limited in terms of the project model, as right now it works only for CMake.

Q: Are ssh keys supported?
A: Yes, they are supported. When configuring the remote toolchain, select the “Key Pair” authentication type.

Q: For remote development on Windows with WSL, can we have rsync to transfer the files? It will be much faster than scp. rsync can be installed on WSL.
A: For WSL it’s better to use a separate WSL toolchain type. In that case, no file synchronization is happening at all, as it’s actually the same memory segment.

Q: How is the mapping created for local and remote folders in the Full Remote Mode? How can I change the remote directory where the source code is synchronized?
A: The configuration process is as follows:

  1. Create a Remote Toolchain in Settings/Preferences | Build, Execution, Deployment | Toolchains (toolchains are IDE-wide – they define the environment and the compiler/debugger executable).
  2. Create a CMake Profile in Settings/Preferences | Build, Execution, Deployment | CMake (there are project-wide – they define the build type and other CMake options).
  3. After step 2, an entry in the Deployment settings (Settings/Preferences | Build, Execution, Deployment | Deployment) appears. The Mappings tab defines the Local/Remote path mappings. By default, CLion creates a directory under the /tmp folder on the Remote host. You can change the path here.

Most notable requests on Full Remote development in CLion

  • Configurations:
    • Open remote CMake project, no requirement for sources stored locally (CPP-14584)
    • Native Docker support (CPP-13751)
  • VCS: Remote VCS support (CPP-14482), VCS branch switching (CPP-14272)
  • Debugger:
    • Launch configuration automatically under gdbserver via ssh for remote debug (CPP-7050)
    • Attach to process on remote host (CPP-14316)
    • An option to provide symbol file for a shared library in case of remote GDB debug with gdbserver (CPP-8236)

There is a set of other bugs and requests linked to this main ticket, CPP-744.


Your CLion Team

Comments below can no longer be edited.

14 Responses to Webinar Recording: Remote Development with CLion

  1. Avatar

    Ben Asys says:

    April 1, 2019

    Are there any plans on making this usable with a native windows remote? Seems weird that it’s not supported out of the box considering Visual C++ can work with cmake just fine.

    • Anastasia Kazakova

      Anastasia Kazakova says:

      April 1, 2019

      What do you mean by native windows remote?

      • Avatar

        Ben Asys says:

        April 2, 2019

        Using a remote visual c++ toolchain to produce windows binaries from a non-windows host machine.

  2. Avatar

    Sean Stewart says:

    April 23, 2019

    I work with a fairly large application whose functional test suite is written in Javascript. While I’m able to build/run the tests just fine, I’m unable to attach a GDB debugger. I receive the following error:

    Error during pretty printers setup: Undefined info command: “pretty-printer”. Try “help info”.

    Some features and performance optimizations will not be available.

    com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver$GDBCommandException: “/path/to/remote/javascript/executable”: not in executable format: File format not recognized

    Process finished with exit code 0

    Is is possible to provide support for executables which are not binaries?

    • Avatar

      Eldar Abusalimov says:

      April 24, 2019

      Do you use JS scripts for running your native binary as a subprocess (with proper env, args, etc.), or you rather build a shared library object and link it from within a JS VM so that the scripts and your native code share the same address space?

      The former case is not supported until we have multi-process GDB support, unfortunately. Please follow https://youtrack.jetbrains.com/issue/CPP-9476 for the updates. The only workaround would be to attach to a running process manually, but this is only supported for local processes at the moment.

      In the latter case I guess it should be possible to specify a VM as the executable and the script as its argument, like `/path/to/remote/nodejs`, arguments: `/path/to/remote/javascript/script.js`. Once a node process loads your shared library you’re be able to stop at breakpoints in the library code, etc.

  3. Avatar

    Den says:

    May 7, 2019

    I am working on a fairly large application, the remote debug feature looks good, great job!

    • Anastasia Kazakova

      Anastasia Kazakova says:

      May 7, 2019


  4. Avatar

    Matthew Huck says:

    September 5, 2019

    Is there any support for synchronizing files from the remote back to the host, our toolchain, as part of the compile uses the clang tools to autofix/autoformat some things, and at the moment I can’t seem to find a way to get those changes back into the local files.

    This is preventing me from using it, I’ve had to switch to VSCode Insiders and use their remote container feature. I would love to switch back to CLion!

    • Avatar

      Vasily Romanikhin says:

      September 5, 2019

      At the moment we sync from remote to local machine only header-roots and cmake generated files, we do not support synchronization of project sources from remote-host to local one.

      • Avatar

        Johan says:

        June 26, 2020

        Vasily: Is this still valid?
        Our toolchain also uses clang-format etc that sometimes changes the code on the remote target.
        Have not found any way to automatically sync changes from remote to local host, have to manually download updated files.

        • Avatar

          Vasily Romanikhin says:

          June 26, 2020

          Unfortunately, at the moment we do not support reverse synchronization of project sources from remote machine to local one.

  5. Avatar

    Craig says:

    October 17, 2019

    Is it possible to cross-compile and remote debug without having to manually copy the binary and launch gdbserver? I’m working on an embedded Linux platform and would rather not have to install the toolchain on the target.

Discover more