With full remote mode, you can work on a macOS, Linux, or Windows desktop targeting a remote Linux machine connected via SSH. You can choose any Linux-based target, including embedded systems on single-board computers like Raspberry Pi. Also, your program can be launched on a cloud platform or, for example, inside a Docker container.
- Actually, CLion synchronizes header search paths with all the content from the remote machine to the local client in order to resolve your code correctly. For example, even though standard library headers are taken from the target, you can navigate to them as if you were working locally in the CLion editor. So you need to have your includes on the remote host and CLion will transfer them.
- Add remote toolchain and set path mappings in Settings - Build,Execution,Deployment - Deployment - select proper remote host - Mappings tab 4. (optionally) Reload CMake Project: Tools - CMake - Reload CMake Project. After that operations initial transfer step has to be skipped.
For remote development, the CLion instance runs locally, and your source files are also placed on the local client, with automatic synchronization to the remote host. On the remote host side, CLion performs compilation and build using host compilers and CMake/make, uses host GDB for debug, and runs the application on the remote target.
When working on a Windows client, keep in mind the following:
Due to the IntelliJ platform issue, you need to set the property value
idea.case.sensitive.fs=truein the idea.properties file (to access the property file, select Help Edit Custom Properties... on the main menu), then restart CLion with cache reset (File Invalidate Caches / Restart... ).
For files synchronization on Windows, CLion relies on its own Remote Host Access and compression on the host side using the tar utility. This mechanism causes the synchronization to perform slower than rsync on macOS and Linux.
Create a toolchain with remote credentials
Go to Settings / Preferences Build, Execution, Deployment Toolchains and select Remote Host from the list of toolchains or click and select Remote Host from the drop-down menu to create a new toolchain.
Click next to the Credentials field. In the dialog that opens, create an SSH configuration and provide the credentials for accessing you remote machine. Existing SSH configurations are available from the drop-down list.
You can also manage SSH configurations in Settings / Preferences Tools SSH Configurations.
After establishing the connection, CLion attempts to detect the tools in default remote locations /usr/bin/cmake and /usr/bin/gdb (or using the full paths, if you have provided manually). When the checks finish successfully, the toolchain is ready for use:
You can make the newly created toolchain the default one (for this, move it to the top of the toolchains list by clicking ). When set as default, the remote toolchain is used for all the projects you create and open in CLion.
For CMake projects, if you set the remote toolchain as default, the default CMake profile will connect to it automatically, so you do not need to configure a separate CMake profile for it.
Click 'Open Project' - code editor should open; Go to 'File' - 'Settings' - 'Build, Execution, Deployment' - 'CMake' Set the generation Path to /build and apply; Finally you should right-click on your top level CMakeList.txt file in CLion and select 'Reload CMake Project' CLion should work properly now.
⓵ Remote Project Introduction Let’s take a look at the debugging experience first: As you see, we can set up breakpoints directly in CLion and check all the variables without typing print variablename. This is way faster and more intuitive than debugging directly within GDB. Select the root folder in the Project tree (you might need to open it with View→Tool Windows→Project), in our case it is actix. Right click →Deployment→Upload to remote machine.
(CMake) Create the corresponding CMake profile
Go to Settings / Preferences Build, Execution, Deployment CMake.
Click to create a new CMake profile, and connect it to your remote toolchain using the Toolchain field:
Alternatively, set the remote toolchain as default and select Use default.
Apply the changes.
(Makefile) Select the remote toolchain in Makefile setting
Go to Settings / Preferences Build, Execution, Deployment Makefile.
Select your remote toolchain in the Toolchain field:
Alternatively, set the remote toolchain as default and select Use default.
Apply the changes.
Use the File Transfer tool window (View Tool Windows File Transfer) to monitor the progress of file synchronization:
Check and adjust the deployment configuration
When you create a connection entity for the remote toolchain, CLion puts it in the list of server access configurations in Settings / Preferences Build, Execution, Deployment Deployment.
CLion automatically configures the paths for your project code synchronization. Use the Mappings tab to change the default mappings (for example, to set a particular remote directory for the copied sources instead of the default tmp folder):
For CMake projects, CLion automatically triggers synchronization when you change deployment settings. You can monitor the process in the File Transfer tool window (View Tool Windows File Transfer ):
When uploading your project to the remote machine, CLion uses the directory containing the top-level CMakeLists.txt as a project root (CPP-23995 ). If your top CMakeLists.txt is located in a different subdirectory, change the local path in the Mappings tab.
When uploading a Makefile project to the remote machine, CLion uses the directory containing the Makefile as a project root (see the general ticket CPP-23995 ). If your Makefile is located in a different subdirectory, change the local path in the Mappings tab.
By default, CLion indexes and synchronizes all the directories listed in CMakeLists.txt. However, if you exclude a directory using the Mark Directory as Excluded action, it will be marked as Excluded path for the remote deployment and will not be synchronized with the remote machine. This is performed automatically when you exclude a folder before configuring a remote toolchain.
You can check and adjust the excluded paths in the dedicated tab of the deployment entry settings:
If you mark a directory as excluded when there is a remote toolchain configured and the project has been synchronized already, CLion will suggest that you update the excluded paths. After the update, the excluded folder will be synchronized further.
If you un-exclude a previously excluded directory, CLion will suggest to update the list of the excluded paths and re-upload the folder to the remote host.
Resync header search paths
To resolve your code correctly, CLion synchronizes header search paths with all the content from the remote machine to the local client. For example, even though standard library headers are taken from the target, you can navigate to them as if you were working locally in the CLion editor.
However, header search paths synchronization can be time-consuming, so CLion performs it automatically only upon the initial file transfer. After that, it is not triggered by CMake or Makefile reloads. So every time you switch the compiler or make changes in your project dependencies, make sure to update header search paths manually by calling Tools Resync with Remote Hosts.
Note that you need to call Resync with Remote Hosts manually for every change in your project dependencies or compilers.
You can also switch to automatic synchronization: set the clion.remote.resync.system.cache key in the Registry (go to Help Find Action or press Ctrl+Shift+A, type Registry, and search for the key by name).
Clion Load Remote Project
Build, run, debug
Now that you have a remote toolchain and the corresponding CMake profile configured, you can build, run, and debug your application and tests in the completely remote way by selecting the proper CMake profile in the Run/Debug configuration switcher:
Below you can find a demo showing how the application output changes depending on the OS that it runs on. Having macOS as a local system, we connect remotely to the Ubuntu target and check the OS name. In this example, code highlighting depends on the OS identifier, so when we switch the CMake profile or resolve context, CLion highlights the corresponding code branch:
Create a new Makefile Application configuration or edit an existing one.
In the Executable field, point CLion to the remote binary.
To quickly find out the path to your project directory on the remote host, call Tools Open Remote Host Terminal.
Save the configuration and use it to run or debug your Makefile application remotely.
For both CMake and Makefile configurations, you can set remote external tools as a Before launch step.
Set environment variables
To configure environment variables for the remote OS, specify them in the beginning of the .bashrc file, before the
# If not running interactively, don't do anythingline.
If your primary shell is not bash, follow the instructions for that particular shell or add
PermitUserEnvironment yesto the sshd_config file, restart the sshd service, and then configure the variables in ~/.ssh/environment.
Enable IPv6 support
To connect to IPv6 networks, you need to make adjustments in CLion JVM options:
Run Help Edit Custom VM Options from the main menu. In the *.vmoptions file that opens, delete the
-Djava.net.preferIPv4Stack=trueline and add the following lines:-Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Stack=true -Djava.net.preferIPv6Addresses=true
In order to use hostnames instead of raw addresses, open C:WindowsSystem32Driversetchosts as Administrator on Windows or /etc/hosts as superuser on macOS/Linux and map the required addresses to the corresponding hostnames.
Each address should be placed on a separate line, followed by at least one whitespace and a list of whitespace-separated hostnames, for example:f381::171d:c61c:c7f3:3a56 my.dev.host1 my.dev.host2 f381::171d:c61c:c7f3:3a26%en0 my.dev.host3
On macOS, you also need to specify the list of the banned network interfaces:
Go to Help Find Action and type Registry.
Find the deployment.macOs.bannedInterfaces key and set a comma-separated list of the interfaces to be banned, for example
Previously we have used nRF5-cmake-scripts to create a CMake project for Nordic nRF52. CLion is a great IDE for developing C and C++ CMake projects, and can also be used to debug the firmware.
First, follow the steps to create a nRF5-cmake-scripts project. When the project is opened in CLion, there is very little left to do.
We need to add a toolchain to use the ARM debugger client. In CLion preferences > Build, Execution, Deployment, create a new toolchain named arm-none-eabi and set the Debugger to “arm-none-eabi-gdb”:
Then we need to use that toolchain for our CMake profile, in CLion preferences > Build, Execution, Deployment > CMake set the Toolchain to “arm-none-eabi”:
Then we just need to create a build configuration. On the top right of the CLion window, click the configuration drop down and “Edit Configurations”. Then Add a new “Embedded GDB Server” configuration:
Clion Remote Compile
Set a name
Share through VCS to share this with other CLion users of your project
Select the flash_bl_merge_<target> target
Select your executable
Set Download executable to None
Set ‘target remote’ args to “tcp:localhost:2331”
Set GDB Server to “/usr/local/bin/JLinkGDBServer”
Set GDB Server args to “-device nrf52 -strict -timeout 0 -nogui -if swd -speed 1000 -endian little -s“
All done! Now you can build this target, which will build the firmware, bootloader, flash to the softdevice, or you can debug. When debugging, if your breakpoint is not hit when the debugger starts, just press the reset button and continue:
Clion Remote Project
You can also view the state of peripherals on the device when debugging. When debugging click the 'Peripherals' tab and click 'Load .svd file':
Clion Remote Loading Cmake Project
Browse to toolchains/nRF5/nRF5_SDK_16.0.0_98a08e2/modules/nrfx/mdk and select the .svd file for your hardware (for nRF52832 use nrf52.svd), then select the peripherals you want to monitor. When the debugger is paused you will then be able to inspect the values of peripheral registers: