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

Posted on September 19, 2018 by Anastasia Kazakova

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.

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:
- 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:
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:

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

#2018.3 #newsletter-cpp #remote dev

Comments below can no longer be edited.

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

fenrir says:
September 19, 2018
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.
AJ Lewis says:
September 19, 2018
Looks like this doesn’t work yet for Windows -> remote linux, which is where I really need it. Is that in the plans?
- Anastasia Kazakova says:
  September 19, 2018
  Local machine on Windows is a case we plan to cover for the 18.3 release
  - AJ Lewis says:
    September 20, 2018
    Great – looking forward to it!
Mark says:
September 19, 2018
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.
- Anastasia Kazakova says:
  September 19, 2018
  Have you checked the workaround for Makefiles projects? https://blog.jetbrains.com/clion/2018/08/working-with-makefiles-in-clion-using-compilation-db/
  - Mark says:
    September 19, 2018
    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:
      September 19, 2018
      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:
        October 7, 2018
        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:
        October 8, 2018
        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.
Alexander says:
September 20, 2018
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:
  September 20, 2018
  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:
    September 25, 2018
    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. 🙂
    - Vasily Romanikhin says:
      September 25, 2018
      Thanks, could you please file a ticket: https://youtrack.jetbrains.com/issues/CPP.
Daniel says:
September 20, 2018
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:
  September 20, 2018
  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:
    October 31, 2018
    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!
Hu Bo says:
September 20, 2018
Does it work for ARM development as well, e.g. Raspberry pi?
- Vasily Romanikhin says:
  September 20, 2018
  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:
    September 20, 2018
    Great! Keep up the good work.
  - Max Hadley says:
    September 20, 2018
    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:
      September 23, 2018
      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)
Andrew Smith says:
September 20, 2018
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:
  September 20, 2018
  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:
    September 21, 2018
    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:
      September 22, 2018
      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.
Mike says:
September 20, 2018
Any plans on supporting WIndows -> Unix ?
Any plans on support Windows with Cygwin -> Unix ?
- Anastasia Kazakova says:
  September 21, 2018
  Yes, we have such plans and we’ll do our best to get it done in 2018.3.
Sanhu Li says:
September 21, 2018
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
- Vasily Romanikhin says:
  September 21, 2018
  If you change mapping folder in “Deployment” section, please run “Reload CMake Project” (Tools -> CMake -> Reload CMake project). In this case CLion automatically sync you sources with remote-host using new path-mapping.
  - Sanhu Li says:
    September 21, 2018
    I tried that and also tried “reset cache and reload project”. In both cases, I got an error “/usr/bin/cmake -DCMAKE_BUILD_TYPE=Release -G “CodeBlocks – Unix Makefiles” /home/lisanhu/tmp
    CMake Error: The source directory “/home/lisanhu/tmp” does not appear to contain CMakeLists.txt.
    Specify –help for usage, or press the help button on the CMake GUI.”
    - Vasily Romanikhin says:
      September 21, 2018
      Unfortunately I couldn’t reproduce described problem, but anyway I filed an issue (https://youtrack.jetbrains.com/issue/CPP-14258). So let’s continue our discussion in the ticket.
      
      As workaround you can try to upload project manually:
      – select project directory
      – “right click” -> Deployment -> Upload_To -> select appropriate server.
      - Sanhu Li says:
        September 21, 2018
        Really appreciate your help! I finally made it!
        I have to add that the remote cmake profile actually disappears, even though I can see it in “Build, Execution, Development”->CMake.
        With upload_to, I still cannot make it compile, so I remove the old profile and create a new one with different names (same name with same configuration does not trigger apply button to work). This time it worked smoothly.
        Really appreciate your help. Perhaps something has messed up with my test project, I’m thinking to create a new one to test this feature. I’ll add more if I could reproduce the problem from scratch.
  - Nicolas Aubry says:
    September 24, 2018
    When I change the mapping folder, I get this :
    
    Cannot generate into /home/naubry/WorkspaceRemote/FORMEUSE_EMS/cmake-build-release Cannot create directory Please either delete it manually or select another generation directory
    
    Even if I delete the local (and remote) folder cmake-build-release…
    - Vasily Romanikhin says:
      September 25, 2018
      Am I right that your project successfully synced to /home/naubry/WorkspaceRemote/FORMEUSE_EMS/ folder? If so could please check that “remote user” account (which is used by CLion) has appropriate permissions.
      - Nicolas Aubry says:
        September 25, 2018
        Yes on the remote I have the project synchronized. The directory is in the home of the “remote user” (i.e. /home/retd/Workspace/FORMEUSE_EMS) — Technically, CLion has created a folder to synchronize the sources… but he can’t make the cmake-build-release folder… it’s strange, right?
        
        Illustration of permissions : https://naubry-drive.mycozy.cloud/public?sharecode=eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJzaGFyZSIsImlhdCI6MTUzNzg4MDcxMSwiaXNzIjoibmF1YnJ5Lm15Y296eS5jbG91ZCIsInN1YiI6ImVtYWlsIn0.mpoOiIHPcPXxc13bvvN53j_fqeZ5mv2ckO-bs2gN3tbtdF3jXUQpk3De6zOTj_k0Ng-WVzYUdvusD_6NcTQSCA&id=d10daec1367ccb48b0e7912611d2f07a
        
        the “remote user” is retd.
      - Vasily Romanikhin says:
        September 26, 2018
        Seems like an issue, could you please open a ticket with precise steps to reproduce. https://youtrack.jetbrains.com/issues/CPP
        
        Thanks in advance.
    - Eric Pederson says:
      October 23, 2018
      Nicolas – I am having the same problem (see https://youtrack.jetbrains.com/issue/CPP-14487). Did you resolve your problem? If so, how did you fix it?
      
      Thanks,
      - David Maestas says:
        December 20, 2018
        I had the same issue and got it working. I changed the root path under deployment options back to the default of “/” and added my home folder prefix to the remote locations under the mappings tab. I had to reset the Cmake cache and reload before it worked.
      - Vasily Romanikhin says:
        December 24, 2018
        Hi @David
        Here’s the ticket connected to root path: https://youtrack.jetbrains.com/issue/CPP-14185
        Please vote.
    - David says:
      July 25, 2019
      Did you create a ticket for this? I see the same behaviour when using a custom mapping with deployment to a raspberry pi (i.e. /home/pi/mydir)
      - Anastasia Kazakova says:
        July 25, 2019
        I think there is some workaround in this thread and a ticket regarding the root path: https://youtrack.jetbrains.com/issue/CPP-1418
Chris Thompson says:
September 21, 2018
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:
  September 22, 2018
  > 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).
  - Chris Thompson says:
    September 24, 2018
    Thanks for filing the ticket. I am able to manually sync the files. I like the feature so far!
Vladimir Bondarevskiy says:
September 21, 2018
Is there support for connecting to IPv6 addresses? I could not connect.
- Vasily Romanikhin says:
  September 22, 2018
  IPv6 is not supported yet. Here’s the ticket https://youtrack.jetbrains.com/issue/CPP-14264.
Anastasia Kazakova says:
September 22, 2018
What’s the remote host in your case?
Joshua Bambrick says:
September 25, 2018
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.
- Joshua Bambrick says:
  September 25, 2018
  Actually, it does appear to work with localhost, but not the proxy-accessed hosts.
Alexey says:
September 26, 2018
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’?
- Joshua Bambrick says:
  September 26, 2018
  That sounds related to my issue https://blog.jetbrains.com/clion/2018/09/initial-remote-dev-support-clion/#comment-72259
  
  I’m not sure it is even possible to do remote development in CLion via a proxy – did you manage to set this up manually?
- Vasily Romanikhin says:
  September 26, 2018
  Could you please try to select Authentication type: OpenSSH Config and authentication agent in Configure Remote Credentials dialog.
  - Joshua Bambrick says:
    September 26, 2018
    Sadly, this did not help my issue.
    - Vasily Romanikhin says:
      September 26, 2018
      Could you please create an issue with detailed description.
      https://youtrack.jetbrains.com/issues/CPP
      
      Thanks in advance.
      - Joshua Bambrick says:
        September 26, 2018
        Done!
        
        See https://youtrack.jetbrains.com/issue/CPP-14285
Susan Smith says:
September 26, 2018
I like the feature!
Kirill Martynov says:
September 27, 2018
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:
  September 27, 2018
  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)
David Rees says:
September 28, 2018
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).
- Anastasia Kazakova says:
  September 28, 2018
  The setup you describe is another version of remote, which we have in mind but for the future, no estimations here.
  - David Rees says:
    December 18, 2018
    Is there a youtrack we can follow for that?
    - Anastasia Kazakova says:
      December 18, 2018
      Not yet. This is some global IntelliJ-platform task and we’ve discussed such possibility several times, but nothing specific or planned for now.
      - David Rees says:
        April 10, 2019
        Thanks. I went ahead and created a feature request for CLion running as a server for a local CLion instance just to have something in YouTrack – https://youtrack.jetbrains.com/issue/CPP-15986.
Iurii Pelykh says:
October 5, 2018
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
- Vasily Romanikhin says:
  October 5, 2018
  Hello,
  
  1. there is an issue about preserving file permissions (https://youtrack.jetbrains.com/issue/CPP-14252).
  
  2. at the moment CLion always dereferences symlinks, if it doesn’t fit you please file a ticket and describe your case.
  Thanks in advance.
  - Iurii Pelykh says:
    October 5, 2018
    Thanks Vasily,
    
    I created a ticket on symlink issue: https://youtrack.jetbrains.com/issue/CPP-14361
Sergey says:
October 31, 2018
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.
- Vasily Romanikhin says:
  November 1, 2018
  Hi, Sergey.
  
  It seems you’ve faced with the follow problem (https://youtrack.jetbrains.com/issue/CPP-14168). The ticket contains workaround, could you please try it. If it doesn’t help you feel free to describe your case in the comments.
Titan says:
November 2, 2018
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:
  November 2, 2018
  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.
  - Titan says:
    November 2, 2018
    – Created a new clion project
    – Add toolchain and cmake from scatch(follow the instruction above)
    – Apply changes and automatically start upload files
    – It showed “Cannot save file /tmp/tmp.4mnAd6Y3I9/cmake-build-debug-remote-host/CMakeFiles/clion-environment.txt”
    – After I reloaded “Cannot generate into /Users/panlv/CLionProjects/untitled/cmake-build-debug-remote-host
    Specified path is not a directory”
    
    “/Users/panlv/CLionProjects/untitled” is local directory.
    - Vasily Romanikhin says:
      November 2, 2018
      Could you please file a ticket: https://youtrack.jetbrains.com/issues/CPP
      - choco says:
        November 20, 2018
        having the same issue here with the same configs
      - Vasily Romanikhin says:
        November 21, 2018
        Hello @choco.
        
        Here’s the ticket, feel free to vote or provide additional details (https://youtrack.jetbrains.com/issue/CPP-14601).
Jason says:
November 2, 2018
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:
  November 2, 2018
  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:
    November 2, 2018
    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:
      November 2, 2018
      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.
      - Jason says:
        November 25, 2018
        Launch automatically under gdbserver via SSH is on the list here:
        https://youtrack.jetbrains.com/issue/CPP-7050
    - Alex Johnson says:
      November 12, 2018
      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:
        November 13, 2018
        > 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:
    May 16, 2019
    “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:
      May 21, 2019
      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
Mehrdad says:
November 5, 2018
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:
  November 5, 2018
  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.
Jason says:
November 6, 2018
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
- Jason says:
  November 6, 2018
  Update: In debugger mode, I got the print to show when appending flush after printf. Now I noticed that the debugger stopped at the printf line every time. I cannot get it to run free flow in debugger mode. So we have 3 problems here:
  1. printf won’t show in debugger mode unless fflush() is used
  2. debugger stopped at printf
  3. Some mysterious message during pretty printer setup
  - Vasily Romanikhin says:
    November 8, 2018
    For points 1 and 2 I’ve created an issue: https://youtrack.jetbrains.com/issue/CPP-14647. Feel free to comment or provide additional details in the ticket.
    
    3. that’s a known issue: https://youtrack.jetbrains.com/issue/CPP-14177
Jason says:
November 6, 2018
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.
- Vasily Romanikhin says:
  November 8, 2018
  That’s a known issue, CLion doesn’t sync files to remote host in case of VCS changes (e.g. switching branches) https://youtrack.jetbrains.com/issue/CPP-14265.
  As workaround you can do the follow:
  – select project directory
  – “right click” -> Deployment -> Upload_To -> select appropriate server.
Mark says:
November 9, 2018
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:
  November 12, 2018
  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:
    November 12, 2018
    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:
    November 13, 2018
    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.
Jun Yu says:
November 16, 2018
This is great functionality. Can I attach to a remote process in local machine? tks
- Anastasia Kazakova says:
  November 16, 2018
  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.
T Klatt says:
November 27, 2018
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?
- Vasily Romanikhin says:
  November 27, 2018
  Unfortunately at the moment there is no way to hide this window. As you noticed internally this issue connected with incorrect error message “No files or folders found to process” https://youtrack.jetbrains.com/issue/CPP-14786. Feel free to vote for that.
Martin says:
November 27, 2018
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?
- Anastasia Kazakova says:
  November 28, 2018
  On the remote host.
frankfangli says:
November 28, 2018
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
- Vasily Romanikhin says:
  November 28, 2018
  Could you please try do to the follow: Tools->CMake->Reset Cache And Reload Project.
  - frankfangli says:
    November 28, 2018
    same error message:
    
    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
    
    [Failed to reload]
    - Vasily Romanikhin says:
      November 29, 2018
      Could you please file an issue with detailed description including STR: https://youtrack.jetbrains.com/issues/CPP
      
      Thanks in advance.
Alexey says:
November 28, 2018
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!
- Anastasia Kazakova says:
  November 28, 2018
  I guess here it is: https://youtrack.jetbrains.com/issue/CPP-14601
  Have you checked that your remote account has appropriate permissions (you can connect to remote host using terminal, run appropriate cmake command manually and check results)?
Tushar Tiwari says:
November 29, 2018
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
- Tushar Tiwari says:
  November 29, 2018
  Also will there be a docker toolchains support?
- Anastasia Kazakova says:
  November 29, 2018
  CLion should be synchronizing the header search paths from the remote host to a local one. Can you navigate from CLion to the system headers? Where does it go?
Tushar Tiwari says:
November 29, 2018
Also will there be a docker toolchains support?
- Anastasia Kazakova says:
  November 29, 2018
  Yes, later we plan to have it
- Vasily Romanikhin says:
  November 29, 2018
  Here’s the ticket about “Docker support”. https://youtrack.jetbrains.com/issue/CPP-13751
  Feel free to vote for that.
Neil says:
November 29, 2018
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:
  November 29, 2018
  Currently remote toolchains are only supported for CMake project model. But you can run any external command from CMake via add_custom_command
pavel says:
December 5, 2018
Am I understand right, that code id built on remote host?
- Anastasia Kazakova says:
  December 5, 2018
  Yes
  - Pavel says:
    December 6, 2018
    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:
      December 6, 2018
      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.
Thomas P. Alexander says:
December 7, 2018
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.
- Anastasia Kazakova says:
  December 8, 2018
  We are sorry for that, could you please create a bug here https://youtrack.jetbrains.com/issues/CPP and describe all your steps and setup, and attach IDE log (Help | Show Log)?
Dave Musicant says:
December 18, 2018
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:
  December 19, 2018
  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:
    December 19, 2018
    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…”.
KP says:
December 21, 2018
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 ?
- Anastasia Kazakova says:
  December 21, 2018
  Please collect a CPU snapshot and share with our support (clion-support@jetbrains.com) so that we can analyze. See the instruction: https://intellij-support.jetbrains.com/hc/en-us/articles/207241235-Reporting-performance-problems
Dedoig says:
January 17, 2019
On a Makefile project if I use compilation-db approach will remote debug work?
- Anastasia Kazakova says:
  January 17, 2019
  Not yet. Currently, Remote mode works only for CMake projects. Other build systems will follow later.
  
  However, if you try configuring Remote GDB Debug configuration and use gdbserver on a remote host (https://blog.jetbrains.com/clion/2016/07/clion-2016-2-eap-remote-gdb-debug/), this might work.
Dedoig says:
January 17, 2019
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:
  January 17, 2019
  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:
    January 18, 2019
    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
- Anastasia Kazakova says:
  January 18, 2019
  You can check the requirements here: https://www.jetbrains.com/help/clion/install-and-set-up-product.html
  - DeDoig says:
    January 19, 2019
    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:
      January 21, 2019
      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:
        January 24, 2019
        Just tried that, same result 🙁
      - Vasily Romanikhin says:
        January 24, 2019
        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.
DeDoig213 says:
January 24, 2019
@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.
- Vasily Romanikhin says:
  January 25, 2019
  > Help -> Debug Log Settings shows no menu option.
  It have to show dialog.
  
  Anyway could you please file a ticket with proper description here https://youtrack.jetbrains.com/issues/CPP.
Thomas P. Alexander says:
February 26, 2019
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:
  February 27, 2019
  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:
    February 27, 2019
    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.
Ernest Zaslavsky says:
February 27, 2019
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?
- Vasily Romanikhin says:
  February 27, 2019
  > BTW, looks like most of the time CLion spending in Collecting files stage.
  Yes, we have a request to improve initial project deployment, here’s the ticket – https://youtrack.jetbrains.com/issue/CPP-14365.
  
  > How about build locally, deploy to remote, run/debug remotely?
  
  Yes, you can do that. Build your project locally as usual, setup deployment configuration (Preferences -> Build,Execution,Deployment -> Deployment) and deploy executable result to remote host. And finally run gdbserver on remote host
  and setup Remote GDB configuration (https://blog.jetbrains.com/clion/2016/07/clion-2016-2-eap-remote-gdb-debug/).
  - Ernest Zaslavsky says:
    February 27, 2019
    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 🙂
    - Vasily Romanikhin says:
      February 27, 2019
      Unfortunately at the moment the process of deploying and running gdbserver is not automated, feel free to vote for this ticket https://youtrack.jetbrains.com/issue/CPP-7050
      - Ernest Zaslavsky says:
        February 27, 2019
        Will do! Thanks!
Ernest Zaslavsky says:
February 27, 2019
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 🙂
Jason says:
March 14, 2019
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:
  March 14, 2019
  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:
    March 14, 2019
    That’s one way to put it, at any time, there should only be 1 active configuration, no ?
    - Anastasia Kazakova says:
      March 15, 2019
      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:
        March 15, 2019
        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:
        March 15, 2019
        You can’t disable CMake Profile if it exists, but you can simply remove one (remote) and that should be it.
Greg Ferrar says:
March 19, 2019
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:
  March 20, 2019
  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:
    March 21, 2019
    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.
Greg Ferrar says:
March 21, 2019
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:
  March 22, 2019
  “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:
    March 29, 2019
    I’m running 2018.3. I’d be happy to try the beta.
    - Anastasia Kazakova says:
      March 29, 2019
      There is 2019.1 release available now.
      - Greg Ferrar says:
        April 9, 2019
        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.
Suruoxi says:
April 12, 2019
How can I make this work if I ssh to an remote server by a jump host ?
- Vasily Romanikhin says:
  April 12, 2019
  It’s not supported. Here’s the feature request https://youtrack.jetbrains.com/issue/WI-14953. Feel free to vote for it.
Liubomyr says:
April 22, 2019
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:
  April 22, 2019
  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.
Maxandre Jacqueline says:
April 24, 2019
Well done! Amazing work. It improves my workflow!
Catalin says:
May 15, 2019
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:
  May 15, 2019
  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
JD says:
May 20, 2019
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:
  May 20, 2019
  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:
    May 20, 2019
    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:
      May 20, 2019
      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:
        May 21, 2019
        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:
        May 21, 2019
        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:
        May 21, 2019
        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.
Dedoig says:
May 21, 2019
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:
  May 22, 2019
  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:
    May 22, 2019
    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:
      May 22, 2019
      Ah, that’s a wordpress subscription, not a jetbrains one then. Do you see an unsubscribe option somewhere then?
      - JD says:
        May 22, 2019
        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:
        May 22, 2019
        Hm, seems some wordpress issue. I’ll try to check if we can manage this somehow.
        
        Anastasia Kazakova says:
        May 22, 2019
        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:
  May 22, 2019
  If you can tell me which address was used to subscribe, I’ll unsubscribe you.
  - Anastasia Kazakova says:
    May 24, 2019
    Unsubscribed you
Jason says:
May 24, 2019
When doing remote development, sometimes I refactor code the IDE got confused about undeclared identifiers (red squiggle), part of the IDE still understands the resolves correctly by letting me “go to definition”.
By doing Invalidate cache and restart I was able to get everything resolved correctly but this is too costly operation. Reloading Cmake project didn’t help.
- Anastasia Kazakova says:
  May 24, 2019
  Maybe some new headers were used in the code and you have to sync them to the local machine? This doesn’t happen in background to avoid performance issues, but there is an action Tools | Resync with Remote Hosts that forces the sync. Have you tried that?
- Jason says:
  May 24, 2019
  Thanks ! Tool -> Resync with Remote host fixed this and was quite fast.
  - Anastasia Kazakova says:
    May 26, 2019
    Good. In the blog post you can find a way to enable the automatic resync. But still be carefull as it might be performance heavy operation.
Martin Mirakyan says:
June 13, 2019
Is it possible to have a non-cmake remote project by importing a non-local compile_commands.json in Compilation Database section?

Right now I have my project configured as a ssh-vagrant project but the IDE doesn’t recognize some libraries and headers because it’s not a completely CMake project. So I was wondering if it’s possible to have a remote compilation database?
- Anastasia Kazakova says:
  June 14, 2019
  It’s not yet supported. Please follow the updates here: https://youtrack.jetbrains.com/issue/CPP-16202
Martin says:
June 14, 2019
For remote non-cmake projects is it possible to set-up a remote “Compilation database”?
Right now there is support for remote CMake projects through Toolchain setup, and there is support for non-CMake projects through Compilation Database setup. But I’m not sure how to setup a remote non-CMake project.
- Anastasia Kazakova says:
  June 14, 2019
  It’s not yet supported. Please follow the updates here: https://youtrack.jetbrains.com/issue/CPP-16202
Hiro says:
July 9, 2019
Have any decisions been made as to whether or not CLion will support remote indexing?

Indexing can really hammer the CPU/RAM so I would like to use a local instance of CLion on my laptop while the indexing runs on a powerful cloud machine.
- Anastasia Kazakova says:
  July 9, 2019
  This is not a question of the decision to be made, but rather a huge piece of work that will affect CLion and IntelliJ-platform. This task is often discussed and planned for some future, but without any clear estimation for now.
Maciej says:
September 9, 2019
Hi,

what about using cmake not installed on remote host but only deployed as a binary not sourced in ssh sessions by default (shared as sdk for specific project)?

I encountered problems when in toolchains tried to use full path to custom cmake, sth like:
Instead of ‘/usr/bin/cmake’ I want to use /home/username/tools/cmake_custom/cmake
haha says:
September 21, 2019
hello, do you have some solutions for my situation?
local: win7
remote server: linux(ubuntu16.04)
but my cmake and dependenies，libraries installed in a docker container on this ubuntu server.
- Anastasia Kazakova says:
  September 21, 2019
  Yes, you just start CLion locally and create a remote toolchain to your docker container. Seems like exactly the case described in the blog post. Have you tried this?
  - haha says:
    September 23, 2019
    docker container installed in my remote server, how can I connect to it in local win7? Let’s call win7 is local, ubuntu server is remote host, docker container in ubuntu server is remote docker.
    following this blog, I can start Clion in local and create a remote toolchain to my remote host, but what should I do to connect the remote docker?
    - Anastasia Kazakova says:
      September 23, 2019
      Can you connect remote toolchain to your remote docker directly using it as a remote host?
      - haha says:
        September 23, 2019
        I can’t. I can only connect to remote server with its ip and port(22), is there some special ip&port configuration to connect to remote docker directly?
      - Vasily Romanikhin says:
        September 23, 2019
        Hello @haha
        
        It seems that you can setup sshd (e.g. on port 2222) in your docker container, then run it and try to setup connection to it.
Clay Edwards says:
October 9, 2019
Part of the our build process involves running some bash scripts that are checked in to git,
with a #!/bin/bash as the top line. The execute permission for the scripts seems to be removed when the script is copied from windows to the linux build machine. Is there a switch somewhere that I haven’t found to control this behavior?
- Anastasia Kazakova says:
  October 10, 2019
  That’s a known limitation. We hope to address it in https://youtrack.jetbrains.com/issue/CPP-17258
Stan Cao says:
October 11, 2019
Hi,

I’m having trouble when trying to use Clion to debug a c Makefile project about using qemu emulating XINU. I installed the project in my local docker. I can use make && make run to run my project in terminal, but I’m a little confused about how should I use Makefile to debug using Clion remote debug. Any suggestions?
- Anastasia Kazakova says:
  October 11, 2019
  Currently, remote projects support works only for CMake projects. What you need will be probably covered by https://youtrack.jetbrains.com/issue/CPP-16202
Steven Ourada says:
October 31, 2019
This is great. I’m a little late discovering it, but now I’ll be using it a lot. Thanks!
DeDoig says:
November 7, 2019
I will be using Clion on OSX and building on a Linux Docker container running locally. I believe there is a way to set up file / folder sharing between the Docker & OSX for my project folder including all source file. Can CLion take advantage of this to, for example, skip syncing?
- DeDoig says:
  November 7, 2019
  … in case relevant, sharing based on https://docs.docker.com/docker-for-mac/osxfs/ supports sending File system events (like creation, modification, etc.) from OSX into Docker.
- Vasily Romanikhin says:
  November 7, 2019
  At the moment in CLion there is no dedicated support for developing in Docker.
  
  > Can CLion take advantage of this to, for example, skip syncing?
  
  At the moment not, but it’s in our plan, feel free to vote for https://youtrack.jetbrains.com/issue/CPP-13751. Anyway I recommend you to try remote-mode + docker. Here’s the shot instruction how to start with that: https://youtrack.jetbrains.com/issue/CPP-13751#focus=streamItem-27-3772888.0-0
Madhukar Dhekale says:
November 24, 2019
Any plans on supporting WIndows -> Linux ?
- Anastasia Kazakova says:
  November 25, 2019
  This is supported already, if you mean Windows as a local machine, Linux as a remote host.
  - Madhukar dhekale says:
    November 25, 2019
    Yes ..clion is windows machine and remote deployment machine is centOS so I am not able to build from clion however I am able to build it directly on centOS.
    
    Someone had mentioned that it is not supported yet and it will be done in next version
Madhukar dhekale says:
November 25, 2019
Yes ..clion is windows machine and remote deployment machine is centOS so I am not able to build from clion however I am able to build it directly on centOS.

Someone had mentioned that it is not supported yet and it will be done in next version
Milan says:
February 14, 2020
Two essential features are missing from this great platform:
1) Support for jump host (ssh module should be able to use .ssh_config file to connect through jump host.
2) Ability to debug on remote machine using “sudo gdb”. I tried common hack of renaming gdb to _gdb and creating bash script that runs “sudo _gdb”, but clion somehow recognizes that gdb is not a valid file.
ZUR says:
March 9, 2020
I just started using the remote dev feature of Clion and I have a couple of questions.

My setup: I am writing code on a local Mac laptop and compile/run/debug in either a local VM or remote servers.

My Questions:
1. I mount my home filesystem in the VM. Can I take advantage of this shared filesystem to avoid sync-ing data constantly?

2. Most of my projects are make based. What is the recommended way of compiling a remote makefile-based project? I see two options but I was not able to make either work reliably: a) compilation database; b) adding a CMakefile with a custom target that just invokes make. Are these options supported for remote compilation?

3. One idea for compiling remotely would be to create a shell script that logs in to the target machine, invokes make, gets all the output, replaces the top-level directory on the target machine with the top level directory on the local machine, and outputs everything for cmake to parse. Did anyone try this approach?

4. To get CMake to index all the files in the project I added a single executable declaration in a dummy CMakeLists.txt file and listed all header and source files as dependencies. This works well but Clion tries to compile this target remotely resulting in errors. How can I achieve the same effect (indexing all project files) but without adding compilations targets to confuse Clion?
- Vasily Romanikhin says:
  March 10, 2020
  Hello @ZUR.
  
  1. No, at the moment we do not support external synchronization.
  2. Only CMake projects are supported in remote development for now.
  I suppose custom CMake target could work, but we didn’t check that case.
  3. I haven’t met such approach. BWT why do you need such tricky compilation process?
  4. While collecting compiler information CLion runs compiler on remote host for each unique compiler switch, please note it doesn’t compile your target remotely.
Jahwan says:
April 2, 2020
Hi, I’m really excited to use clion-remote 🙂
I’m having some test after following steps from this page.

when I run the code remotely with Clion, I got these errors. is it related with permission?
I ran it on ssh terminal, got a same errors.

OpenCV(3.4.1) /home/owner/opencv/modules/core/src/utils/filesystem.cpp:320: error: (-215) handle != -1 in function Impl
[ WARN:16] Initialized OpenCL cache directory, but interprocess synchronization lock is not available. Consider to disable OpenCL cache: OPENCV_OPENCL_CACHE_DIR=disabled
[ INFO:16] Preparing OpenCL cache configuration for context: NVIDIA_Corporation–GeForce_RTX_2080_Ti–440_59
[ERROR:16] Can’t create file: /home/owner/.cache/opencv/3.4.1/opencl_cache/NVIDIA_Corporation–GeForce_RTX_2080_Ti–440_59/core–copyset_f8f028f1776dc5c98bf03411d3b72318.bin
…
- Jahwan says:
  April 2, 2020
  it seems related with permission when using openCL or CUDA.
  when I connect it with ssh and use sudo, then it works well.
  - Jahwan says:
    April 2, 2020
    nevermind 🙂 it works pretty well !
    - Anastasia Kazakova says:
      April 3, 2020
      Ok, glad it works finally) Let us know if more issues.
Jan says:
April 14, 2020
Hello,

I have a question about Mac -> Windows. I’ve set up the remote so it is syncing, but my CMake requires some packages (libsystemd etc) using pkg_check_modules. I want it to look for these packages at remote, but CLion looks for them locally. Is this possible?

Thanks
- Anastasia Kazakova says:
  April 14, 2020
  In Remote mode, only Linux as a remote OS is supported for now.
Igor says:
April 14, 2020
Is it possible to automatically download build targets from the remote OS to the host after a successful build?
- Vasily Romanikhin says:
  April 16, 2020
  Unfortunately at the moment we have no dedicated “Download” action.
  But you can “Run External Tool” after build step in RunConfiguration. For example you can run scp user@remote:/tmp/project/prog /home/user/project/prog command and download binary artefact to your local machine.
  - Igor says:
    April 16, 2020
    Thank you for the answer, Vasily.
Furkat says:
April 27, 2020
Failed to include *.cmake file from parallel directory. And as I can see in file transfer it transferred only files from root CMakeFile.txt directory. How can I transfer files from parallel to root directory?
- Vasily Romanikhin says:
  April 27, 2020
  Pleas do the follow:
  1. change Project Root to parent directory which includes your current directory and “parallel” directory: Tools -> CMake -> Change Project Root
  2. change path mapping to new one: Preferences -> Build, Execution.. -> Deployment -> select proper host -> Mappings
  3. call Tools -> CMake -> Reload CMake Project
Igor says:
April 29, 2020
I work with the large codebase so source files synchronization takes too long, also complex projects sometimes might become inconsistent. I wonder if it possible having the project with all source files on the remote machine only (something like SSH extension for Visual Studio Code Remote)
- Anastasia Kazakova says:
  April 29, 2020
  We are considering this approach to remote. However, it requires significant technical work to be done. Anyway, we have to consider how to resolve the code (locally or remotely transferring the results to the local machine). There are a few solutions for that we are trying now.
  
  Anyway, speaking of the synchronization – it should be long time only the first time. Does it resynch completely often? And what do you mean by inconsistent here? Can you please provide more details?

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

Initial remote projects support – what’s that?

How to configure a remote project in CLion?

Remote development – what can I do?

What’s going on in CLion under the hood?

Resync with Remote Hosts

Stay fully remote all the time with ease

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

fenrir says:

AJ Lewis says:

Anastasia Kazakova says:

AJ Lewis says:

Mark says:

Anastasia Kazakova says:

Mark says:

Anastasia Kazakova says:

Alexey says:

Anastasia Kazakova says:

Alexander says:

Anastasia Kazakova says:

Alexander says:

Vasily Romanikhin says:

Daniel says:

Anastasia Kazakova says:

Derek Bailey says:

Hu Bo says:

Vasily Romanikhin says:

Hu Bo says:

Max Hadley says:

Max Hadley says:

Andrew Smith says:

Vasily Romanikhin says:

Andrew says:

Vasily Romanikhin says:

Mike says:

Anastasia Kazakova says:

Sanhu Li says:

Vasily Romanikhin says:

Sanhu Li says:

Vasily Romanikhin says:

Sanhu Li says:

Nicolas Aubry says:

Vasily Romanikhin says:

Nicolas Aubry says:

Vasily Romanikhin says:

Eric Pederson says:

David Maestas says:

Vasily Romanikhin says:

David says:

Anastasia Kazakova says:

Chris Thompson says:

Vasily Romanikhin says:

Chris Thompson says:

Vladimir Bondarevskiy says:

Vasily Romanikhin says:

Anastasia Kazakova says:

Joshua Bambrick says:

Joshua Bambrick says:

Alexey says:

Joshua Bambrick says:

Vasily Romanikhin says:

Joshua Bambrick says:

Vasily Romanikhin says:

Joshua Bambrick says:

Susan Smith says:

Kirill Martynov says:

Vasily Romanikhin says:

David Rees says:

Anastasia Kazakova says:

David Rees says:

Anastasia Kazakova says:

David Rees says:

Iurii Pelykh says:

Vasily Romanikhin says:

Iurii Pelykh says:

Sergey says:

Vasily Romanikhin says:

Titan says:

Vasily Romanikhin says:

Titan says: