The recording of our webinar Remote Development with CLion is available on the JetBrainsTV YouTube channel.
Outline:
- 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
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
rsyncis 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 usessftpandgzipcompression 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 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:
The same goes for 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:
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:
The synchronization process is displayed in the File Transfer tool window (View | Tool Windows | File Transfer):
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:
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:
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!
Your CLion Team
JetBrains
The Drive to Develop
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.
Looks like this doesn’t work yet for Windows -> remote linux, which is where I really need it. Is that in the plans?
Local machine on Windows is a case we plan to cover for the 18.3 release
Great – looking forward to it!
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.
Have you checked the workaround for Makefiles projects? https://blog.jetbrains.com/clion/2018/08/working-with-makefiles-in-clion-using-compilation-db/
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?
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.
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”
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.
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.
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
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.
Thanks, could you please file a ticket: https://youtrack.jetbrains.com/issues/CPP.
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.
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.
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!
Does it work for ARM development as well, e.g. Raspberry pi?
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.
Great! Keep up the good work.
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!
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)
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?
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.
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.
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.
Any plans on supporting WIndows -> Unix ?
Any plans on support Windows with Cygwin -> Unix ?
Yes, we have such plans and we’ll do our best to get it done in 2018.3.
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
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.
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.”
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.
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.
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…
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.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.
Seems like an issue, could you please open a ticket with precise steps to reproduce. https://youtrack.jetbrains.com/issues/CPP
Thanks in advance.
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,
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.
Hi @David
Here’s the ticket connected to root path: https://youtrack.jetbrains.com/issue/CPP-14185
Please vote.
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)
I think there is some workaround in this thread and a ticket regarding the root path: https://youtrack.jetbrains.com/issue/CPP-1418
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?
> 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).
Thanks for filing the ticket. I am able to manually sync the files. I like the feature so far!
Is there support for connecting to IPv6 addresses? I could not connect.
IPv6 is not supported yet. Here’s the ticket https://youtrack.jetbrains.com/issue/CPP-14264.
What’s the remote host in your case?
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.
Actually, it does appear to work with localhost, but not the proxy-accessed hosts.
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’?
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?
Could you please try to select Authentication type:
OpenSSH Config and authentication agentin Configure Remote Credentials dialog.Sadly, this did not help my issue.
Could you please create an issue with detailed description.
https://youtrack.jetbrains.com/issues/CPP
Thanks in advance.
Done!
See https://youtrack.jetbrains.com/issue/CPP-14285
I like the feature!
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)
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 runtouch .clion.source.upload.marker)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).
The setup you describe is another version of remote, which we have in mind but for the future, no estimations here.
Is there a youtrack we can follow for that?
Not yet. This is some global IntelliJ-platform task and we’ve discussed such possibility several times, but nothing specific or planned for now.
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.
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
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.
Thanks Vasily,
I created a ticket on symlink issue: https://youtrack.jetbrains.com/issue/CPP-14361
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.
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.
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.)
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.
– 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.
Could you please file a ticket: https://youtrack.jetbrains.com/issues/CPP
having the same issue here with the same configs
Hello @choco.
Here’s the ticket, feel free to vote or provide additional details (https://youtrack.jetbrains.com/issue/CPP-14601).
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.
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 )
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 ?
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.
Launch automatically under gdbserver via SSH is on the list here:
https://youtrack.jetbrains.com/issue/CPP-7050
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.
> 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-pathsif “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.
“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.
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.markerto 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/MyProject5. Run
Tools -> CMake -> Reset Cache and Reload ProjectHi,
I’ve installed CLion.v2018.2.5 but there is no remote option in
Settings/Preferences | Build, Execution, Deployment | Toolchains
any idea?
Thanks,
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.
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
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
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
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.
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.
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?
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.
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.
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.
This is great functionality. Can I attach to a remote process in local machine? tks
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.
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?
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.
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?
On the remote host.
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
Could you please try do to the follow: Tools->CMake->Reset Cache And Reload Project.
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]
Could you please file an issue with detailed description including STR: https://youtrack.jetbrains.com/issues/CPP
Thanks in advance.
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!
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)?
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
Also will there be a docker toolchains support?
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?
Also will there be a docker toolchains support?
Yes, later we plan to have it
Here’s the ticket about “Docker support”. https://youtrack.jetbrains.com/issue/CPP-13751
Feel free to vote for that.
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.
Currently remote toolchains are only supported for CMake project model. But you can run any external command from CMake via add_custom_command
Am I understand right, that code id built on remote host?
Yes
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.
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.
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.
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)?
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?
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'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…”.
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 ?
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
On a Makefile project if I use compilation-db approach will remote debug work?
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.
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?
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
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
You can check the requirements here: https://www.jetbrains.com/help/clion/install-and-set-up-product.html
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.
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.
Just tried that, same result
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_hosts3. goto Preferences -> Build,Execution,Deployment -> Deployment -> Select appropriate Host -> Mappings -> change Deployment Path to
/tmp/test_project_424. Run “Reload Cmake Project”
If it doesn’t help you please add
#com.jetbrains.cidr.remoteto 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 withCLion teamvisibility.@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.
> 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.
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?
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.gitfrom the list.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.
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
rsynctakes 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 filesstage.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?> 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/).
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 lazyI want to build locally, press that little green
bugbutton and voila, process runs remotely, debugger is attached,sysrootis configured automatically, all bells and whistles like break points work as expected.Yes, I lknow, I’m asking too much
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
Will do! Thanks!
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 lazyI want to build locally, press that little green
bugbutton and voila, process runs remotely, debugger is attached,sysrootis configured automatically, all bells and whistles like break points work as expected.Yes, I lknow, I’m asking too much
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 ?
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?
That’s one way to put it, at any time, there should only be 1 active configuration, no ?
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.
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.
You can’t disable CMake Profile if it exists, but you can simply remove one (remote) and that should be it.
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?
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.webDeploymentThen 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 teamvisibility.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.
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?
“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?
I’m running 2018.3. I’d be happy to try the beta.
There is 2019.1 release available now.
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.
How can I make this work if I ssh to an remote server by a jump host ?
It’s not supported. Here’s the feature request https://youtrack.jetbrains.com/issue/WI-14953. Feel free to vote for it.
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.
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.
Well done! Amazing work. It improves my workflow!
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?
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/myproject2. put empty file
.clion.source.upload.markerto 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/myprojectHi, 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?
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.
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?
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.
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.
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.
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.
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 !
Do you mean you are subscribed to the blog? You can update these settings here then: https://info.jetbrains.com/user-mailing-preferences.html
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.
Ah, that’s a wordpress subscription, not a jetbrains one then. Do you see an unsubscribe option somewhere then?
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.
Hm, seems some wordpress issue. I’ll try to check if we can manage this somehow.
Ok, seems we managed to find proper place in the wordpress settings and update them. So I removed you from the subscription.
If you can tell me which address was used to subscribe, I’ll unsubscribe you.
Unsubscribed you
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.
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?
Thanks ! Tool -> Resync with Remote host fixed this and was quite fast.
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.
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?
It’s not yet supported. Please follow the updates here: https://youtrack.jetbrains.com/issue/CPP-16202
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.
It’s not yet supported. Please follow the updates here: https://youtrack.jetbrains.com/issue/CPP-16202
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.
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.
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
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.
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?
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?
Can you connect remote toolchain to your remote docker directly using it as a remote host?
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?
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.
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?
That’s a known limitation. We hope to address it in https://youtrack.jetbrains.com/issue/CPP-17258
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?
Currently, remote projects support works only for CMake projects. What you need will be probably covered by https://youtrack.jetbrains.com/issue/CPP-16202
This is great. I’m a little late discovering it, but now I’ll be using it a lot. Thanks!
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?
… 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.
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
Any plans on supporting WIndows -> Linux ?
This is supported already, if you mean Windows as a local machine, Linux as a remote host.
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
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