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:

Questions
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.

Cheers!

Your CLion Team

This entry was posted in Webinar and tagged , , , , , . Bookmark the permalink.

10 Responses to Webinar Recording: Remote Development with CLion

  1. Ben Asys says:

    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.

  2. Sean Stewart says:

    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?

    • Eldar Abusalimov says:

      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. Den says:

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

  4. Matthew Huck says:

    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!

    • Vasily Romanikhin says:

      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.

Leave a Reply to Ben Asys Cancel reply

Your email address will not be published. Required fields are marked *