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

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

Initial remote projects support – what’s that?

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

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

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

How to configure a remote project in CLion?

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

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

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

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

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

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

Remote development – what can I do?

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

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

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

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

What’s going on in CLion under the hood?

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

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

Stay fully remote all the time with ease

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

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

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

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

Download CLion 2018.3 EAP

Your CLion Team

JetBrains
The Drive to Develop

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

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

  1. fenrir says:

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

  2. AJ Lewis says:

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

  3. Mark says:

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

      • Mark says:

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

        • Anastasia Kazakova says:

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

          • Alexey says:

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

          • Anastasia Kazakova says:

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

  4. Alexander says:

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

    • Anastasia Kazakova says:

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

      • Alexander says:

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

  5. Daniel says:

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

    • Anastasia Kazakova says:

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

      • Derek Bailey says:

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

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

  6. Hu Bo says:

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

    • Vasily Romanikhin says:

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

      • Hu Bo says:

        Great! Keep up the good work.

      • Max Hadley says:

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

        So far so good!

        • Max Hadley says:

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

  7. Andrew Smith says:

    Thanks!

    I have two questions:

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

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

    • Vasily Romanikhin says:

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

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

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

      • Andrew says:

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

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

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

        • Vasily Romanikhin says:

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

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

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

  8. Mike says:

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

  9. Sanhu Li says:

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

  10. Chris Thompson says:

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

    • Vasily Romanikhin says:

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

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

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

  11. Vladimir Bondarevskiy says:

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

  12. Anastasia Kazakova says:

    What’s the remote host in your case?

  13. Joshua Bambrick says:

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

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

  14. Alexey says:

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

    Say, I have a record there:

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

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

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

  15. Kirill Martynov says:

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

    • Vasily Romanikhin says:

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

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

  16. David Rees says:

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

    • Anastasia Kazakova says:

      The setup you describe is another version of remote, which we have in mind but for the future, no estimations here.

  17. Iurii Pelykh says:

    Hello,

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

    Thanks

  18. Sergey says:

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

    But I ran into difficulty. Strange magic happens.

    From CLion:

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

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

  19. Titan says:

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

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

    • Vasily Romanikhin says:

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

  20. Jason says:

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

    • Anastasia Kazakova says:

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

      • Jason says:

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

        • Anastasia Kazakova says:

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

        • Alex Johnson says:

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

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

          • Vasily Romanikhin says:

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

            Seems it’s already done.

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

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

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

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

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

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

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

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

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

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

  21. Mehrdad says:

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

    any idea?

    Thanks,

    • Anastasia Kazakova says:

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

  22. Jason says:

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

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

    Some features and performance optimizations will not be available.

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

  23. Jason says:

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

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

  24. Mark says:

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

    I can ssh in OK directly from a terminal window.

    Any advice on how to configure this?

    • Alex Johnson says:

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

      • Alex Johnson says:

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

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

      • Vasily Romanikhin says:

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

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

  25. Jun Yu says:

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

    • Anastasia Kazakova says:

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

  26. T Klatt says:

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

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

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

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

  27. Martin says:

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

  28. frankfangli says:

    I encounter below error :

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

    Please either delete it manually or select another generation directory

  29. Alexey says:

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

    Does anyone have a similar issue?

    Thanks!

  30. Tushar Tiwari says:

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

  31. Tushar Tiwari says:

    Also will there be a docker toolchains support?

  32. Neil says:

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

    • Anastasia Kazakova says:

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

  33. pavel says:

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

    • Anastasia Kazakova says:

      Yes

      • Pavel says:

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

        • Anastasia Kazakova says:

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

  34. Thomas P. Alexander says:

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

Leave a Reply

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