Stay local, let your IDE do remote work for you!

The recording of our webinar Remote Development with CLion is available on the JetBrainsTV YouTube channel.

Outline:

CLion’s issue tracker has dozens of important and interesting feature suggestions to implement. With limited resources, we are always having to prioritize the features we include with the direction we have in mind for the product’s evolution. 3-digit issues with over 800 supportive votes – these are the kinds of requests we can’t leave out! Can you guess the one we’re working on for v2018.3? It is all about remote projects support!

Initial remote projects support – what’s that?

We’ve started with a particular set-up, though we do plan to cover and come to up with more cases in the future. So we are calling the current support state – initial. What exactly was implemented then?

  • Local client machine: macOS, Linux or Windows
  • Remote host: Linux
  • Sources location: originally on the local host, CLion will synchronize to the remote machine for you.
  • Project model: only CMake projects
  • rsync is required to be installed on a remote host in case your local machine is macOS or Linux, when Windows is used as a local machine – CLion uses sftp and gzip compression to synchronize the sources.

We know there are many other cases for remote development and we are planning to extend our support for it in the future. Just sit tight and stay tuned!

How to configure a remote project in CLion?

It is much easier than you imagine! Just follow these steps.

  1. First of all, go to Settings/Preferences | Build, Execution, Deployment | Toolchains:

    • Create a new toolchain (we call it Remote in our sample)
    • Select the Remote Host option
    • Configure the credentials to access the remote host:
      remote_host_mac_credits
    • Set paths to the CMake executable and debugger on the remote host (it has to be done manually for now, while the default /usr/bin/cmake and /usr/bin/gdb are set for you)

    Now, if the remote host is accessible by ssh with the given address, port, username and password, the toolchain check will finish successfully and the toolchain will be available for use in CLion:
    remote_connected

  2. Now you need to connect a CMake profile (the one that currently exists, or a newer one) to the newly added remote toolchain. Do this under Settings/Preferences | Build, Execution, Deployment | CMake:
    remote_cmake_profile
    Later in this blog post, we’ll see how we can skip this step by simply making the remote toolchain the default one.

After applying these changes, CLion will reload the CMake on this project and you’ll then be ready to start working remotely with your project in CLion:
remote_cmake_reload

Remote development – what can I do?

Now you have a remote toolchain configured and a CMake profile that uses it. Using then our Debug-Remote as an example. You can now:

  • run your app
  • debug your app
  • run tests
  • debug tests

All completely remotely from the instance of CLion on your local machine. And it’s really then as easy as just selecting a proper CMake profile in the build type switcher:
remote run ap
The same goes for tests:
remote run tests

We hope to enable Valgrind and Google Sanitizers in the remote mode soon as well.

What’s going on in CLion under the hood?

Let me now briefly explain what CLion actually does when the described ‘remote configuration’ operations are performed. If you are not interested in the inner mechanics, then feel free to simply skip this part.

During the first step the connection entity is created, you can review the settings under Settings/Preferences | Build, Execution, Deployment | Deployment:
remote_web_deployment
Mappings tab settings, the deployment path, in particular, is configured automatically by CLion and has the path to the remote host where CLion synchronizes your project code:
remote_deployment_path
The synchronization process is displayed in the File Transfer tool window (View | Tool Windows | File Transfer):
file_transfer_toolwindow
Apart from synchronizing the local files to the remote host, CLion also grabs header search paths with all the content to the local host, so it can resolve your code correctly. This means that the standard library headers, for example, are taken from your remote machine, but you can navigate to them as you would to the local files with CLion’s editor.

Resync with Remote Hosts

In the full remote development mode, the CLion instance runs locally and synchronizes header search paths from the remote machine to the local host (to resolve the code correctly in CLion). Triggering the synchronization of the header search paths on every CMake reload might be a time-consuming task. Thus the resync is performed only when triggered manually, by calling Tools | Resync with Remote Hosts.
The registry option clion.remote.resync.system.cache allows you to change the behavior and resync on every reload.

Starting CLion 2019.1.2 update you can enable clion.remote.upload.external.changes registry option (Help -> Find Action, type Registry). If this option is enabled CLion will automatically resync changes which were made out of IDE scope, e.g. changing VCS branch or updating git repo in terminal.

Stay fully remote all the time with ease

To end this introduction into this awesome new feature, we’d like to share with you a very simple way to use CLion in this remote mode for all your projects, existing and new.
Go to Settings/Preferences | Build, Execution, Deployment | Toolchains and make your remote toolchain a default one by simply moving it to the top of the toolchains list:
remote default toolchain

Now, this remote toolchain will be used automatically for all the projects you open in CLion. For example, when you checkout a new project from Git:
open remotely

There are a few known issues already, they are linked to the parent ticket here. For example, a potential performance issue when too many remote toolchains are created.

That’s it! Give this CLion remote development feature a try and let us know what you think!

Download CLion 2018.3 EAP

Your CLion Team

JetBrains
The Drive to Develop

This entry was posted in Announcement, Tips'n'Tricks and tagged , , . Bookmark the permalink.

181 Responses to Stay local, let your IDE do remote work for you!

  1. fenrir says:

    Since I’m apparently too dumb to create a working modern tool chain for the Raspberry Pi and running CLion on it is not an option, this is really great news.

  2. AJ Lewis says:

    Looks like this doesn’t work yet for Windows -> remote linux, which is where I really need it. Is that in the plans?

  3. Mark says:

    This is a great start, but since my project uses Make (CPP-494 which is slightly higher in +1 than this feature) I will need to wait to test this feature out. Still, I am glad to see that JetBrains is at least working on one of the top request features.

      • Mark says:

        Yes, I know about this, but I am hoping for something other than a workaround. So, based upon your comment, do I take it that JetBrains does not plan on implementing CPP-494 and the solution is a workaround?

        • Anastasia Kazakova says:

          We plan to implement native makefiles support in the future, but can’t provide exact estimations here. From the other hand, the workaround should work nicely for many cases.

          • Alexey says:

            From the article I understood the remote debugging will work only for CMake project, implying the makefile workaround above will not support remote debugging. Am I wrong?
            I’ve been successfully using the above makefiles workaround for a couple of months now, but only for development and refactoring of a code running on a remote machines (and manual debug). If it becomes possible now to also debug it from Clion, that would be a game changer in our team.
            If indeed possible, perhaps you could update that article (or add a new one?) on how to achieve that with makefile project? I hope it’s not “convert your project to CMake” :-)

          • Anastasia Kazakova says:

            Currently it works only for CMake, will consider wider functionality a bit later. This is a huge piece of work and we just started from CMake. But we won’t limit it with CMake in general in future.

  4. Alexander says:

    I have failed to select compilation profile in EAP edition. It using default toolchain (some toolchain – I have tried to change default). So, I have no chance to change it.
    Remote Cmake have completed successfully but I didn’t managed to get remote compilation.

    • Anastasia Kazakova says:

      Do you mean that CLion can’t detect remote compilers? Can you please attach a screenshot of the Toolchain settings. Here or create an issue in https://youtrack.jetbrains.com/issues/CPP

      • Alexander says:

        I have located the problem
        1. I have opened project (it was automatically build by default toolcahin)
        2. I have changed toolchain in CMake settings (got new profile Debug-remote)
        3. This profile didn’t appear in configuration selector (first problem!). So I have renamed it to Debug
        4. Because cmake-build-debug already existent CLion try to build it on default toolchain. Removing local cmake-build-debug folder didn’t helps.
        5. now if you go to remote server and remove cmake-build-debug folder from the temporary folder /tmp/tmp.XXXXXXXX and reload cmake project you will be able to build it remotely. :)

  5. Daniel says:

    Supporting toolchains on a remote host is great and good, but what about CLion support for cross compilation toolchains actually running on the same machine? This would be much more trivial to support.

    • Anastasia Kazakova says:

      What you mean under cross-compilation support? Since CLion calls CMake directly for CMake projects and CMake works nicely with cross-compilation toolchains, it should work successfully in CLion. If you mean some particular issue with that, please let us know.

      • Derek Bailey says:

        I agree with Anastasia. I have successfully used Clion as a cross-compilation IDE on the same machine. It just requires configuring the CMake Options correctly with the -DCMAKE_TOOLCHAIN_FILE option to point to your toolchain.

        I am excited to try out the remote host with cross-compilation though!

  6. Hu Bo says:

    Does it work for ARM development as well, e.g. Raspberry pi?

    • Vasily Romanikhin says:

      Yes, I’ve just checked it. I installed cmake and compilers on my Paspberry Pi (os: Raspbian). After that configured appropriate remote toolchain, as result CLion can successfully build, run and debug my program on RaspberryPi.

      • Hu Bo says:

        Great! Keep up the good work.

      • Max Hadley says:

        I just tried it, creating a hello world project on my Mac and configuring remote operation as the post describes. A couple of very minor things:
        – The spinning gearwheel for compiler autodetection continues to spin even when you manually enter the executables’ paths. Ignore it.
        – The version of cmake in the Raspbian repos is well behind that installed on the Mac. I had to manually edit CMakeLists.txt (on the Mac) to use version 3.7 instead of 3.12.

        So far so good!

        • Max Hadley says:

          Also, it is necessary to run ‘File>>Reload CMake Project’ after each reboot of the Pi (as I discovered after the power here went out, briefly)

  7. Andrew Smith says:

    Thanks!

    I have two questions:

    1. Does remote debugging still require gdbserver (and therefore require transferring potentially huge symbols from the remote host to the local client)?

    2. Will the remote development experience eventually support code analysis on the remote host (auto-complete, find all references, etc), to avoid pegging local CPU/RAM?

    • Vasily Romanikhin says:

      1. If you configure remote-toolchain (as described in this post) remote debugging doesn’t require gdbserver.

      2. Code assistance like navigation, code completion and etc is available in remote mode. The development experience looks like you work locally, but CLion uses remote header search paths and tools like compilers, cmake, make and gdb.

      What about CPU/RAM? If we talking about running cmake and project compilation that processes consume resources of your remote machine. So the compilation can be much faster if your remote host is more powerful than local laptop. Other processes, e.g. building symbols are local.

      • Andrew says:

        1. In that case, is there any server component/process running (if not gdbserver) set up by CLion that allows remote debugging? Does that process require full debug symbols to be transferred from the remote host to the local client?

        2. For me, in local mode, CLion frequently uses many GB of RAM in the background (which slows the computer and also causes frequent garbage collection and associated UI pauses). Similarly, it often uses a lot of CPU. I’m assuming this is related to building symbols and maintaining in-memory indices as code changes. I was hoping that eventually (even if not for this initial release), there would be a server component that would do all of this (just communicating the results to the client on demand), that could take advantage of the much more powerful remote host to do the resource-intensive work.

        I’m not talking about actually compiling the code via clicking build in CLion. (CLion doesn’t support our build system, so I need to build with a different process regardless.) I’m just talking about the work it needs to do in order to support navigation/autocomplete/refactoring/etc.

        • Vasily Romanikhin says:

          1. If your build system is CMake there is no additional component/process set up by CLion which allows remote debugging. We sync sources to remote host, build/compile them using remote cmake and remote compilers and finally run remote GDB and communicate with this remote GDB-process via stdin/stdout. As result we no need to transfer debug symbols.

          Below you mentioned that you use other build system, as result it’s impossible to build/run your program via CLion and, as result, at the moment it impossible to debug in that way.

          2. I see, in the platform there were some discussions about remote indexing (or even headless IDE). But at the moment CLion’s remote-mode works in different way.

  8. Mike says:

    Any plans on supporting WIndows -> Unix ?
    Any plans on support Windows with Cygwin -> Unix ?

  9. Sanhu Li says:

    Can I know how to change the mapping folders? I find if I change the mapping folder under “Deployment”, the files will not sync to the new mapping path. Since not all the time we have enough space in tmp on remote host and it’s much better if we could map the code to some place under home folder

  10. Chris Thompson says:

    This seems like a great feature! It will help me maintain my sanity with regards to different keyboard layouts. I ran into a problem, though – I had to change my mapping for the local and remote dir, since I needed some config files one folder up in my tree. When I changed the mapping the file sync worked like a charm. Then I switched git branches and it won’t sync additional files from the new branch. I modified one of the new files locally, and it was sent to the remote machine, but the other files are still only local. “Reload CMake Project” didn’t help. How can I trigger a sync of the full tree?

    • Vasily Romanikhin says:

      > How can I trigger a sync of the full tree?

      1. Because of you need some config files one folder up your project directory, you can “Change Project Root” (Tools -> CMake -> Change Project Root)
      2. In “Deployment” section set appropriate path mapping – one folder up (according to your description you already did that)
      3. Select required folder and upload it to the server by “right click” -> Deployment -> Upload_To -> select server.

      Also I filed the ticket about automatic synchronisation with remote host after VCS branch switching (https://youtrack.jetbrains.com/issue/CPP-14265).

  11. Vladimir Bondarevskiy says:

    Is there support for connecting to IPv6 addresses? I could not connect.

  12. Anastasia Kazakova says:

    What’s the remote host in your case?

  13. Joshua Bambrick says:

    I have a proxy setup in /etc/ssh/ssh_config which uses ProxyCommand to connect to some hosts via a proxy. Whenever, I attempt to connect set up a connection, I repeatedly get “Cannot establish a connection” from CLion.

    It is possible that this is unrelated to my proxy setup, as I get the same message whenever I enter localhost as the host to connect to.

  14. Alexey says:

    It would be nice to take ssh configuration defined in ~/.ssh/config and make them available.
    But unfortunately it doesn’t work… Or am I miss something (about how to config)?

    Say, I have a record there:

    host ubuntu64
    Hostname 192.168.1.5
    Port 333
    User alexey
    ProxyCommand ssh homerouter -W %h:%p

    That is, from console I simple type ‘ssh ubuntu64’ and have nothing to know about any proxies, ports, different usernames, keys, etc. It ‘just work’.

    How can I just point the name of the section without repeating these boring things like port, username, address, etc, since everything actually necessary is already typed once in ~/.ssh/config? Could it also ‘just work’?

  15. Kirill Martynov says:

    Unfortunately Exclude paths in Deployment tab doesn’t work.
    If I use my vagrant machine and connect using ssh with CLion, it starts uploading .vagrant folder of my project to vagrant machine, and that takes forever, since this folder contains disk images (>50 Gib)

    • Vasily Romanikhin says:

      Seem I could reproduce the problem, https://youtrack.jetbrains.com/issue/CPP-14275.

      As temporarily workaround I can suggest the follow:
      1. Create remote toolchain, interrupt automatic project uploading
      2. Add appropriate exclude path
      3. Synchronise project manually ( select project directory
      –> “right click” -> Deployment -> Upload_To -> select server.)
      4. On remote host, in project directory create empty file .clion.source.upload.marker (you can just run touch .clion.source.upload.marker)

  16. David Rees says:

    I’m excited to see CLion is looking at remote development options. But for my company’s use cases we really need a model where a CLion server would run on the remote server and do all indexing there. Bringing all the source over to the client (or doing all the indexing over sshfs) just isn’t an option due to the size of the codebase.
    So we are looking for something similar to the Language Server Protocol model (but with CLion’s richer support).

  17. Iurii Pelykh says:

    Hello,

    I found that CLion doesn’t preserve symlinks and file permitions while sync with remote host.
    Is it possible somehow to set appropriate options for rsync?

    Thanks

  18. Sergey says:

    That’s great!!! I build the docker container and the whole environment, including cmake gcc and so on, now based on ubuntu is completely identical to production

    But I ran into difficulty. Strange magic happens.

    From CLion:

    — Build files have been written to: /tmp/tmp.c0Fy1NX27x
    Cannot read /Users/sergey.tarasov/Work/Projects/sre/iqlogger/cmake-build-debug/CMakeFiles/TargetDirectories.txt
    Cannot read CMake dependency information from /Users/sergey.tarasov/Work/Projects/sre/iqlogger/cmake-build-debug/CMakeFiles/Makefile.cmake

    On the remote host (docker container) files exists and cmake . doesn’t throw any errors.

  19. Titan says:

    macOS 10.14.1 as local machine
    ubuntu 18.04 as remote
    Problems:
    Project files uploaded succeed. But the CMake tool window logs”Cannot save file /home/XXX/CLionProjects/cmake-build-debug-remote-host/CMakeFiles/clion-environment.txt”

    “/home/XXX/CLionProjects/” is the deployment mappings I set. (Using default mappings is no good too.)

    • Vasily Romanikhin says:

      Could you please check that your remote account has appropriate permissions (also you can connect to remote host using terminal, run cmake manually and check results). If it doesn’t help you could you please file an issue with precise steps to reproduce.
      Thanks in advance.

  20. Jason says:

    So am I right this simply means that Clion syncs source code files to remote target and let remote target compiles the project. This is slow and not as efficient as Clion lets host cross compiles the code and only ssh the binary files in. The former requires complete toolchain dependency while the latter only requires gdbserver presence. I think this is very different from Eclipse remote system support.

    • Anastasia Kazakova says:

      There are two different scenarios supported now in CLion:
      1) Cross-compile locally, sync (manually) a binary to remote host, create and run Remote GDB configuration, which allows remote debugging via gdbserver
      2) Fully remote case, when CLion build, run, debug your app on remote machine. Currently the sources are synchronized from the local host to remote. In future we plan to implement the case, where sources are remote already and we simply work with them there, synching to local host for code resolve in the IDE. The source code on local host is necessary so that you have the same code assistance as if you work on remote host (like completion, resolve, highlighting, refactorings and etc )

      • Jason says:

        That clarifies it a lot! It would be great if Clion can fully support case #1, automatic transfer binary to remote host and automatically manages gdb debug session. This minimizes syncing traffic and does not put a lot of resource requirements on the remote host (eg: raspberry pi or other embedded..). I imagine use case #1 should be majority users. Do you know why Clion wanted to tackle use case #2 first and what would the typical development context is this for ?

        • Anastasia Kazakova says:

          The case #1 is already implemented, I guess for a year now. It only requires to transfer the binary. But I guess you can set the automatic sync via a bundled remote host access plugin in Settings/Preferences | Build, Execution, Deployment | Deployment. So should be fine.

        • Alex Johnson says:

          Why I want scenario #2: My team uses shared remote development boxes with a particular configuration/toolset/environment which we can’t replicate to our local machines. Most of the code is version controlled into our own user directories on the server, though they all share the same core configuration/toolset/environment. Code editing is traditionally done through ssh terminals using vim. I find that this limits my productivity. While these machines do have X11 forwarding and I’m able to run CLion from my user directory (alas, no sudo rights for proper installation), the performance is rather poor and impacts all of the other developers. I would prefer to run CLion on my local machine, and have it sync with an existing codebase on the server where the actual build/debug commands are run (which would fail on my local machine).

          How I hope this ends up working:
          •I would prefer that the sync process between my local system and the server have nothing to do with CMake and be based entirely on file system changes.
          •I would prefer to run version control commands on the server, either manually or via integrated CLion support. I do NOT want to create commits/changelists/checkins on my local machine since these could become out of sync with version control on the development server (not talking about the master/depot/repository server for the version control system).
          •I’d prefer that the synchronizing happen at a configurable interval, and automatically when running remote make/build/debug commands.
          •I would like to be notified if there’s a conflict between my local changes and file changes on the server.
          •I’m okay with CLion keeping a local cache of the codebase so that it can perform its indexing and insight magic without wasting server CPU/IO. I would like this cache to be updated, if necessary, every time changes from the server are pulled in.
          •I do not want to run any build commands or tools on my local machine. I simply want CLion to execute them on the server when needed and pipe the output back to itself to display to the user.

          • Vasily Romanikhin says:

            > I would prefer that the sync process between my local system and the server have nothing to do with CMake and be based entirely on file system changes.

            Seems it’s already done.

            > I would prefer to run version control commands on the server, either manually or via integrated CLion support. I do NOT want to create commits/changelists/checkins on my local machine since these could become out of sync with version control on the development server (not talking about the master/depot/repository server for the version control system).

            That’s our weak point, at the moment there is no integration with remote VCS. Here are related tickets:
            https://youtrack.jetbrains.com/issue/CPP-14482
            https://youtrack.jetbrains.com/issue/CPP-14265

            > I’d prefer that the synchronizing happen at a configurable interval, and automatically when running remote make/build/debug commands.

            At the moment we sync from local to remote host in each “write” action (e.g. saving document, building/running executable).

            > I would like to be notified if there’s a conflict between my local changes and file changes on the server.

            That intersects with your previous comment about remote VCS, there is no conflict at the moment because of lacking this functionality.

            > I’m okay with CLion keeping a local cache of the codebase so that it can perform its indexing and insight magic without wasting server CPU/IO. I would like this cache to be updated, if necessary, every time changes from the server are pulled in.

            At the moment CLion re-syncs all header-search-paths if “Reload Cmake Project” is called.

            > I do not want to run any build commands or tools on my local machine. I simply want CLion to execute them on the server when needed and pipe the output back to itself to display to the user.

            That’s already done. All tools (cmake, compilers, debugger) we execute in remote-mode are remote.

      • Alexander Johnson says:

        “In future we plan to implement the case, where sources are remote already and we simply work with them there, synching to local host for code resolve in the IDE.”

        Any word on this? Are there any open tickets or feature requests I could subscribe to? I’d love to have two-way synchronization between my CLion machine and the remote. With the current one-way synchronization I have to ssh into the remote to view/edit any generated artifacts using vim. It would be nice to view these directly in CLion after building.

        • Vasily Romanikhin says:

          Hello, here’s the feature request https://youtrack.jetbrains.com/issue/CPP-14584. Feel free to vote for that. I will add a workaround to the ticket description.

          Workaround:
          1. Put empty file .clion.source.upload.marker to the root of the project (e.g. cat /tmp/MyProject/.clion.source.upload.marker)
          2. Download project sources from remote host (e.g. using rsync or scp)
          3. In CLion configure remote toolchain, open project, interrupt automatic project uploading
          4. Open preferences -> Build,Execution,Deployment -> Deployment -> Select Appropriate Host -> Mappings -> set deployment path to /tmp/MyProject
          5. Run Tools -> CMake -> Reset Cache and Reload Project

  21. Mehrdad says:

    Hi,
    I’ve installed CLion.v2018.2.5 but there is no remote option in
    Settings/Preferences | Build, Execution, Deployment | Toolchains

    any idea?

    Thanks,

    • Anastasia Kazakova says:

      Yes, as the post says it will be available in 2018.3. Which is now in EAP, so you can grab a free preview build and give it a try. There is a list in the end of the blog post.

  22. Jason says:

    Any idea to get printf to stdout to work ? I got a “hello world” program that I got it to build, run and print to Clion “console” window.
    But when running under debugger, I do not see any print on the console window at all. A message was shown and that was it:

    Error during pretty printers setup: Error while executing Python code.

    Some features and performance optimizations will not be available.

    /tmp/tmp.w2qVbkm4OB/cmake-build-debug-remote-host/demo

  23. Jason says:

    After more than an hour of testing, there is apparently a cache issue with Remote build system. I started with a project which failed to compile. Then a git pull was done to update the code (outside of clion). The new code is confirmed to compile on a different system. Now with Clion it still didn’t want to compile no matter what I did. I did reload cmake, close, exit, I even “invalidated cmake cache and restart”. I know there was a cache issue because the error pointed to an old line of code in clion IDE. This means remote system still got an old copy of the code, while the clion IDE got a new copy.

    Finally, to fix this issue, I ssh in the remote system and deleted everything in the /tmp folder that clion created.

  24. Mark says:

    This is great functionality. However, I am currently trying to test this to remote deploy/debug to an AWS linux server (ubuntu) from a MAC. On the toolchains screen, it is failing to connect to the remote host using SSH. I have it set top as “KeyPair OpenSSH or Putty”, and have tried with either the amazon PEM key file or the puttygen version ppm file. It says cannot establish connection.

    I can ssh in OK directly from a terminal window.

    Any advice on how to configure this?

    • Alex Johnson says:

      Similar issue here. SSH from a terminal works fine using either a passphrase or a private key. CLion “cannot establish connection” using the same passphrase or the same private key. I’ve triple checked and the port, username, and server address are all identical. Not sure what else to try.

      • Alex Johnson says:

        I found more settings under Build->Deployment (As opposed to Build->Toolchain). When testing the connection, I discovered that CLion thinks my PuTTy generated RSA key is corrupt. This is the exact same file that I use for SSH every day outside of CLion.

        Fortunately, password authentication works from this menu. After returning to the toolchain menu I found that it was no longer failing there.

      • Vasily Romanikhin says:

        Hi @Mark and @Alex_Johnson
        Here’s the ticket around “OpenSSH config and establishing connection”:
        https://youtrack.jetbrains.com/issue/CPP-14580

        I have added links to your comments. Feel free to vote and provide additional details in the ticket.
        Thanks in advance.

  25. Jun Yu says:

    This is great functionality. Can I attach to a remote process in local machine? tks

    • Anastasia Kazakova says:

      Do you mean the process you start remotely and outside CLion and you’d like to attach to it from the local CLion? Then, no, not yet.

  26. T Klatt says:

    I really love the remote toolchain support. It makes my live so much easier here.

    There is just one really big annoyance I’m facing: The File Transfer Tool Window keeps popping up whenever the warning/error “No files or folders found to process” is emitted. This usually occurs while editing CMakeLists.txt files and having auto-reload enabled.

    I was able to disable the green balloon via Settings | Appearance | Notifications | Web Deployment but not the un-hiding of the window itself.

    Is there a way to display the auto-unhiding of the File Transfer Tool Window on such messages?

  27. Martin says:

    When running/debugging an application that has a GUI, where does this get displayed, on the machine that is running CLion or the remote host?

  28. frankfangli says:

    I encounter below error :

    Cannot generate into D:\cpp\untitled\cmake-build-debug-remote
    Specified path is not a directory

    Please either delete it manually or select another generation directory

  29. Alexey says:

    I am trying to configure Remote Toolchain in CLion Linux. After adding credentials CLion could find cmake and debugger and seems to be hanging on make, gcc and g++. After adding cmake configuration for remote build following error pops up:
    Cannot save file /tmp/tmp.yG5avr/cmake-build-debug-remote-host/CMakeFiles/clion-environment.txt

    Does anyone have a similar issue?

    Thanks!

  30. Tushar Tiwari says:

    I’m currently using this with the remote server in a docker container. I am able to build, debug and run from within CLion. But my CLion’s autocomplete doesn’t work. It seems like it can’t find the installed system libraries

  31. Tushar Tiwari says:

    Also will there be a docker toolchains support?

  32. Neil says:

    Is there any method to configure remote build command instead of built in cmake? In my environment, my projects use same code is used for different product line. In my case, we need to specify a particular build environment by a specified shell script and build our project with special shell script with special parameter.
    So the builtin cmake isn’t useful, we need the customized build command to replace the cmake. And it’s better we can set multi customized build target for different product line.

    • Anastasia Kazakova says:

      Currently remote toolchains are only supported for CMake project model. But you can run any external command from CMake via add_custom_command

  33. pavel says:

    Am I understand right, that code id built on remote host?

    • Anastasia Kazakova says:

      Yes

      • Pavel says:

        Thanx for the answer. Is there standard way (suppored from the box) to cross compile code on my local machine and deploy app (and sources) to remote host, then run app under debugger? Remote host often is not the best place to compile big project.

        • Anastasia Kazakova says:

          1. You can cross-compile easily with CMake. Just point it to the cross-compilers and provide necessary options.
          2. You can build the app locally and sync the results and sources to the remote machine using the Web Deployment settings (provide credentials and folders to sync).
          3. Then you can setup a GDB remote debug via gdbserver. There is a special configuration in the Run/Debug configurations templates. For now, we can’t run the debug automatically via ssh (this is planned under https://youtrack.jetbrains.com/issue/CPP-7050), so you have to use this special configuration
          4. You can using remote terminal (added in 2018.3.1) to start gdbserver on a remote host right from the IDE.
          5. Now run this special Run/DEbug configuration from CLion and debug on a remote host.

  34. Thomas P. Alexander says:

    I’m glad to see this feature as it may be very useful to speed compilations and to use with docker containers. However I’m unable to get it to work and I think there are still some serious bugs in here. I followed the instructions carefully and got green lights for all of the remote tools. Initially the remote sync worked and my project files uploaded. But I could not get the remote configuration to be a selectable option, it would not show up in the drop-down list. I added an environment variable to the remote configuration and after that all of my build configurations were blown away, showing “Nothing to run.” I removed the env variable and it’s still stuck in the same mode. I now don’t even have my previous release and debug configurations.

  35. Dave Musicant says:

    This is fantastic functionality, and I’m looking forward to making considerable use of it. Question: when I run a buggy executable on a remote Linux system, and it crashes with a segfault, I can’t see that as cleanly as I can see it when it is local. When I run the executable locally, I’ll happily see “Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)”. When I run it remotely, I just get “Process finished with exit code -1”. I can verify that if I ssh into the remote system and manually run the executable, it does segfault just like it does locally.

    Is there some way I can enable CLion to more accurately show me the segfault on the remote machine, rather than a generic -1 error code?

    • Vasily Romanikhin says:

      Thanks Dave.

      I’m not sure that it’s CLion problem. The reason could be your sshd server.
      I’ve just tried it with my remote host and I see the follow output for invalid binary:
      bash: line 1: 13399 Segmentation fault (core dumped) env "JETBRAINS_REMOTE_RUN"="1" "NSUnbufferedIO"="YES" '/tmp/tmp1/cmake-build-debug-remote-host/prog'

      • Dave Musicant says:

        Thanks, Vasily — you’ve fixed it. :) I mean, of course you haven’t via your post, but for reasons I can’t explain, I’m now seeing the same behavior that you just reported.

        It’s true that we were playing around with server and login settings yesterday when trying to troubleshoot what turned out to be https://youtrack.jetbrains.com/issue/CPP-14881. Maybe we flipped something, or maybe it is somehow related to something that changed (we changed?) in the /tmp directory up on the server. But I’m quite sure that today is the first time I’m seeing any output whatsoever on remote execution that starts with “bash…”.

  36. KP says:

    This feature works just the way I want. Love it. Just have one issue regarding performance. Is there a way to speed up the IDE. The CPU fan keeps running. I’m on MacBook Pro Core i5, 8G RAM etc.. Remote is Ubuntu. I tried the “Power Save Mode” and it things get much better but I need completion to work.

    Any suggestions ?

  37. Dedoig says:

    On a Makefile project if I use compilation-db approach will remote debug work?

  38. Dedoig says:

    I do not have full control of the remote server to install gdbserver, but my Makefile is simple enough that I might just try to rewrite it for CMake.

    What versions of cmake, make, clang, and gdb are required / supported?

    • Dedoig says:

      Also, I get this error after configuring (apparently successfully) when I try to remotely build and run the default “Hello World” program:

      Error: could not find CMAKE_PROJECT_NAME in Cache

      • Anastasia Kazakova says:

        Can you run CMake remotely by hands successfully? It looks like some old project name is stuck in CMake Cache. You can try removing the Cache and rerun the CMake: Tools | CMake | Reset Cache and Reload project

      • DeDoig says:

        I now have a remote configuration (set as Default), CLion has no complaints, and a new default Hello World project. I get this when I open the project:

        File Transfer panel (all seems ok):
        [2019-01-18 22:14] Upload to Remote Host (0c034182-7445-4fef-83ba-e775d395ca2b)
        [2019-01-18 22:14] Upload file ‘/Users/ashley/CLionProjects/test3/CMakeLists.txt’ to ‘/tmp/tmp.7LjioG3Jq5/CMakeLists.txt’
        [2019-01-18 22:14] Upload file ‘/Users/ashley/CLionProjects/test3/main.c’ to ‘/tmp/tmp.7LjioG3Jq5/main.c’
        [2019-01-18 22:14] Upload to Remote Host (0c034182-7445-4fef-83ba-e775d395ca2b) completed in less than a minute: 2 files transferred (9.4 kbit/s)

        CMake panel (has errors, and no Run buttons enabled):
        /usr/bin/cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_MAKE_PROGRAM=/usr/bin/make -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -G “CodeBlocks – Unix Makefiles” /tmp/tmp.7LjioG3Jq5
        — The C compiler identification is Clang 3.4.2
        — Check for working C compiler: /usr/bin/clang
        — Check for working C compiler: /usr/bin/clang — works
        — Detecting C compiler ABI info
        — Detecting C compiler ABI info – done
        — Configuring done
        — Generating done
        CMake Warning:
        Manually-specified variables were not used by the project:

        CMAKE_CXX_COMPILER

        — Build files have been written to: /tmp/tmp.7LjioG3Jq5/cmake-build-debug
        Cannot read /Users/ashley/CLionProjects/test3/cmake-build-debug/CMakeCache.txt

        [Failed to reload]

        I have tried all combinations of clearing Cache and restart. I cannot find any CMakeCache.txt that CLion says it cannot read.

        Local client: OSX 10.12.6
        Remote host: RHEL 7.6 (not a Docker or any container)
        rsync is installed on the remote host.

        Help.

        • Anastasia Kazakova says:

          The easiest way now is probably to recreated the remote toolchain. Remove it from CLion settings along with the CMake profile using this remote toolchain. Then recreate, CLion will resync the project to the new directory and seems everything should be fine then.

          • DeDoig says:

            Just tried that, same result :(

          • Vasily Romanikhin says:

            Hi @DeDoig

            Could you please do the follow:
            0. Do not remove existing remote-toolchain
            1. remove all locally cmake generated directories: e.g. cmake-build-debug*
            2. remove local file ~/.ssh/known_hosts
            3. goto Preferences -> Build,Execution,Deployment -> Deployment -> Select appropriate Host -> Mappings -> change Deployment Path to /tmp/test_project_42
            4. Run “Reload Cmake Project”

            If it doesn’t help you please add #com.jetbrains.cidr.remote to Debug Log Settings (Help -> Debug Log Settings), then reproduce the problem and share logs with us (Help -> Compress Logs & Show in Finder) in ticket https://youtrack.jetbrains.com/issue/CPP-14881. Please note logs may contain sensitive information, so feel free to attach logs with CLion team visibility.

  39. DeDoig213 says:

    @Vasily Romanikhin tried that, no change. (No “reply” button on your message)

    Help -> Debug Log Settings shows no menu option.

    It is a shared server. I have 3 green check marks on my (remote) Toolchains dialog.

    What should root_path setting be? I tried the default “/” and also tried “Autodetect” and neither one made a difference.

  40. Thomas P. Alexander says:

    When files are synced, the .git folder is automatically omitted, even though it’s not listed in the “Excluded Paths” section. Is there a way that I can force it to be included?

    • Vasily Romanikhin says:

      Yes, you can do that but please note at the moment CLion doesn’t support work with remote VCS:
      Preferences -> Build,Exection,Deployment -> Deployment -> Options -> find "Exclude items by name" and remove .git from the list.

      • Thomas P. Alexander says:

        Thanks, Vasily. My reason for needing this is that git status is extracted and used to create a header file in the build, this is a dependency in our cmake.

  41. Ernest Zaslavsky says:

    Ok, after playing with “Hello World!”ish CLion project on my remote (which is Kubernetes pod) I’ve tried to drop it to the real project. Frustration.

    After setting all local/remote folders to minimize transfer time I got
    > [2/26/19 6:17 PM] Upload to Remote Host (7068af63-143a-4666-8d07-744f19e7b5e8) completed in one hour one minute: 5,721 files transferred (31.6 kbit/s)
    When rsync takes couple of seconds to complete.
    >rsync -rvz -e ‘ssh -p 1977’ -hP ./ root@127.0.0.1:/TeSt –include=”ext**” –include=”proc**” –include=”lib**” –include=”utils**” –exclude=”*”
    >sent 30.09M bytes received 113.33K bytes 6.71M bytes/sec
    >total size is 99.53M speedup is 3.29

    Of course, when your pod is deleted and new one is created you have to wait another hour to sync files. BTW, looks like most of the time CLion spending in Collecting files stage.

    Second point. My build tool chain quite complicated with a lot of third parties managed by vcpkg. I cant afford running it each time I use another remote, it will take ages to get started. How about (if the local and remote are the same type of machines) build locally, deploy to remote, run/debug remotely?

  42. Ernest Zaslavsky says:

    Thats it… as per your reply to the first comment back in September remote development does not require gdbserver. In your scenario it is too much stuff to do manually, sorry, I’m lazy :)
    I want to build locally, press that little green bug button and voila, process runs remotely, debugger is attached, sysroot is configured automatically, all bells and whistles like break points work as expected.
    Yes, I lknow, I’m asking too much :)

  43. Jason says:

    Hi, I have 2 Cmake target configured: local and Remote. The issue is even though I use Local configuration most of the time I notice the IDE still does a File Transfer sync for the Remote target configuration. This is undesirable as it slows down my local development and especially there is error in the Cmakelist (some hardcoded file path) that the Remote target configuration is not compatible yet. Another issue would be the Remote target is sometimes offline, the IDE keeps complaining that it cannot sync. This is very annoying as the active configuration is Local, I don’t care about the Remote. What can you do to mitigate this problem ?

    • Anastasia Kazakova says:

      Do you mean that you need both configurations, but use Remote just occasionally and would like to “freeze” its activity for a while, w/o actually removing it?

      • Jason says:

        That’s one way to put it, at any time, there should only be 1 active configuration, no ?

        • Anastasia Kazakova says:

          Hm, why? If the developer switches regularly, not only between local – remote, but between compilers, compilation flags sets, build types, then he/she can use several configurations at a time.

          • Jason says:

            I use Local configuration most of the time so I expect fast cmake reload but in reality it took way too long to sync and reload remote build configuration which I don’t concern with at this point. Especially when the Cmakelist works for local config but not for the remote config because of missing libs; or even when the remote target is offline.
            It is true that once the developer switches configuration then it should sync or reload, but not necessarily do the remote sync for every local build. I know it does this because I look at the timestamp in File Transfer window. The IDE does a remote upload every time I build a local config.

          • Anastasia Kazakova says:

            You can’t disable CMake Profile if it exists, but you can simply remove one (remote) and that should be it.

  44. Greg Ferrar says:

    This seems useful, and simple, but I can’t get past the SSH connection. I’ve got a docker container with cmake, rsync, opensshd, and port 2222 from the host to 22 of the container. I can ssh just find from the Mac host using Terminal:

    (base) lxm-5q2jg5l:~ greg.ferrar$ ssh -p 2222 developer@localhost which cmake
    developer@localhost’s password:
    /usr/bin/cmake

    But in CLion, when I create a Remote toolchain,

    Credentials=ssh://developer@localhost:2222

    It just says, “cannot establish connection”. Like it’s not getting through on ssh/2222 at all. What could cause this? Is there at terminal command I could run which duplicates exactly how CLion is trying to connect?

    • Vasily Romanikhin says:

      Hello.
      Hmm… sounds strange because your case seems quite simple.
      Could you please add the follow lines to Help -> Debug Log Setting
      #com.intellij.ssh
      #com.jetbrains.plugins.webDeployment
      Then reproduce the problem and attach the log file (Help -> Show Log …) to the ticket https://youtrack.jetbrains.com/issue/CPP-14580

      Please note logs may contain sensitive information, so feel free to attach logs with CLion team visibility.

      • Greg Ferrar says:

        Thanks, Vasily. I found the problem, and it was totally mine. I was using a Docker container for the CLion remote Linux machine, and I was also using a Virtual Box virtual Linux for other purposes. Both were running at the same time, and I had mapped port 2222->22 in *both* cases. Somehow, the Terminal ssh was picking up the port mapping to the container, but the CLion connection was getting nothing. Using two different ports for the two different Linux port maps, fixed the problem.

  45. Greg Ferrar says:

    Just about everything is working now, building and running a fairly large console project with CLion on macOS, remote to a Docker Ubuntu container, and reasonably quickly, but when I Reload CMake Project, it takes 2-3 minutes. to complete. Without using the remote feature, this whole process takes about 5 seconds. Using remote, it quickly (5 seconds) gets through everything up to “[Finished]”, but it then takes a couple minutes before it’s actually [Finished]. File Transfer tab shows no activity. I see things above that suggest that this is using rsync (which I would expect to take just a few seconds for this 5GB folder, if there were no changes), and other things that seem to suggest it’s just using SFTP (which could totally take severally minutes if it’s trying to transfer 5GB). “Activity Monitor” suggests that there is no significant network *or* disk activity during this period. Does it actually use rsync? Any idea why it would take this long vs. local?

    • Vasily Romanikhin says:

      “Reload CMake Project” is not just re-building the project. The most time-consumption step is collecting compiler information. It means that for each unique compiler-switch we create response-file and compiler-file, than run compiler and analyse output.

      As result in remote mode all this operations (including IO operations) have additional “remote” overhead. At the moment we are working on performance in remote-mode, the ticket https://youtrack.jetbrains.com/issue/CPP-15607 was closed several days ago and the fix available in latest CLion Beta. Now it works twice faster than initial version of remote-development, but it’s still slower than the local one.

      @Greg which CLion version do you use?

      • Greg Ferrar says:

        I’m running 2018.3. I’d be happy to try the beta.

        • Anastasia Kazakova says:

          There is 2019.1 release available now.

          • Greg Ferrar says:

            With CLion 2019.1, “Reload CMake Project” time drops from 2-3 minutes (which is what it took for my project using CLion 2018.3), to 10 seconds. Much better! Still 2x slower than local, but definitely useable.

  46. Suruoxi says:

    How can I make this work if I ssh to an remote server by a jump host ?

  47. Liubomyr says:

    Very nice feature.

    I was thinking about similar idea some time ago. But what I would like to see is that code is indexed on remote machine.

    We have quite big, CMake based project that can only be configured and built on Linux.

    Apparently using Linux as development platform is pure pain — problems with hardware, problems with audio and proprietary communication software. So people typically work from Windows and use Visual Studio only for editing code, making fake projects just to index the code and then manually syncing changed files via SSH with locally ran linux VM. Another even more popular setup is to have linux VM running locally with graphics and run either QtCreator or Clion. Both approaches are not good enough.

    • Anastasia Kazakova says:

      Actually indexing on local machine means faster IDE actions, as code resolve happens locally. However, it uses the libraries and the include header search paths from the remote machine.

      However, for the future we plan a setup with remote indexing.

  48. Maxandre Jacqueline says:

    Well done! Amazing work. It improves my workflow!

  49. Catalin says:

    Appreciate the effort, but it seems like it’s unusable for larger projects with lots of files as the upload time is way too high (file by file). Isn’t there any other options to speed things up?

    • Vasily Romanikhin says:

      There is a ticket about that https://youtrack.jetbrains.com/issue/CPP-14365. Please note this issue is in the plan to be fixed in coming 2019.2 release.

      As workaround you can try the follow:
      1. manually copy sources of the project to remote host (remove .git (or .svn) drectory) for example /tmp/myproject
      2. put empty file .clion.source.upload.marker to the root of the project (/tmp/myproject)
      3. in CLion open preferences -> Build,Execution,Deployment -> Deployment -> Select Appropriate Host -> Mappings -> set deployment path to /tmp/myproject

  50. JD says:

    Hi, can I work with CLion in such a way that I develop on Windows, cross-compile on remote Debian/x64 machine, but run on different Debian/armhf machine?

    • JD says:

      I mean can I do it without any extra steps. I believe I can do it by juggling files between machines by hand and running remote debugger with specific configuration, but I’d like to know if I can simply set it up once have all copying done automatically in the background.

      • Anastasia Kazakova says:

        You can probably sync with some rsync automatically. And use Remote GDB server configuration for remote debug.
        And for building, do you really need to get to the remote machine to do that, or can just cross-compile from your local machine?

        • JD says:

          No, I need to compile on remote machine. It is not just a matter of cross-compiler, but also installed packages – lots of them. We tried to create proper sys-root, but we gave up after few days of trying.

          From what you wrote I gather that it would be possible to support scenario that I described by possibly creating some scripts that would be run as a pre-debugging step? Could you point me to documentation? I’m evaluating Eclipse, VS2019 and CLion as potential tools, right now only theoretically, I don’t want to install something that won’t be at least potentially able to satisfy me needs.

          • Anastasia Kazakova says:

            When you want to build on a remote machine while running CLion on your local machine, then use full remote mode.
            After that, you have to set some synchronization from the first remote host to another remote host where you’ll debug with gdbserver from your local CLion.
            Pls see this https://www.jetbrains.com/help/clion/remote-development.html for documentation on both cases.

          • JD says:

            Anastasia, I can’t reply directly to your comment below, so I’ll write it here. Judging from the fact that building and debugging are separated steps I assume that there is no way to do it “naturally”, but I see that I can run External Tool before starting debug session, which means that I can create required setup without much work. I just hoped that things from “Steps of the workflow”, namely point 2, can be take care of by the IDE – since you index remote system anyway and started binary is the one I built (in standard case) I thought that bullets “provide symbol file location” and “set up path mapping” could be done automatically.
            In fact we have quite a few programs, bigger and smaller, and minimal configuration requirements would be great.

            Anyway, thank you very much for your answers.

          • Anastasia Kazakova says:

            We plan to automate the gdbserver remote debug, implementing it over a regular ssh w/o additional steps, but for now we have this flow only.

  51. Dedoig says:

    I have tried multiple times to unsubscribe to notifications on this page but the unsubscribe does not work. Help, please, JetBrains — hopefully simpler than CLion remote builds ! :)

    • Anastasia Kazakova says:

      Do you mean you are subscribed to the blog? You can update these settings here then: https://info.jetbrains.com/user-mailing-preferences.html

      • JD says:

        I believe that he did what I did – when you post, you can check this box “Notify my of followup comments via e-mail. You can also subscribe without commenting”. I did exactly that and now receive *all* updates for this single blog post – not only “followup comments”. I tried to unsubscribe by following procedure linked in each email I receive, but it simply does not work, for example I got information regarding your message that I’m currently replying to. I believe that this is what he meant.

        • Anastasia Kazakova says:

          Ah, that’s a wordpress subscription, not a jetbrains one then. Do you see an unsubscribe option somewhere then?

          • JD says:

            Yes, in the mail with updates that I receive I get the following information:

            Manage your subscriptions: http://blog.jetbrains.com/clion/comment-subscriptions/?sre=&srk=

            This brings me to a page where I have to enter my email address, and after that I can manage my subscriptions. I select the one that I got, select “Delete” radio button below, and click “Update subscriptions”. I acknowledge warning that this operation can’t be undone and this brings me back to the page where I can enter my email address. When I enter it I can see that the subscription is good and well. I can repeat it few times and nothing really happens.

          • Anastasia Kazakova says:

            Hm, seems some wordpress issue. I’ll try to check if we can manage this somehow.

          • Anastasia Kazakova says:

            Ok, seems we managed to find proper place in the wordpress settings and update them. So I removed you from the subscription.

    • Anastasia Kazakova says:

      If you can tell me which address was used to subscribe, I’ll unsubscribe you.

Leave a Reply to Daniel Cancel reply

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