<\/p>\n\n\n\n
Read on to learn more about the updates we have planned.<\/p>\n\n\n\n
Our team is committed to creating an IDE that makes development smooth and productive. However, the following is only a preliminary roadmap. We can\u2019t guarantee that all issues and features listed below will be addressed or implemented in CLion 2026.2. Unexpected circumstances could require us to change our plans or implementation timelines for some items.<\/em><\/p>\n\n\n\n The upcoming release will bring a unified configuration workflow, a more flexible variable inspection experience, and the ability to assign breakpoints to specific debug configurations.<\/p>\n\n\n\n Currently, there is no simple way to configure the debugger \u2013 you have to deal with different settings: Toolchains<\/em>, Run\/Debug Configuration<\/em>, Debug Servers<\/em>, and sometimes DAP Debuggers<\/em>. This gets even more complicated for embedded projects.<\/p>\n\n\n\n In the next release, we plan to introduce a new settings section, tentatively called Debug Profile<\/em>, that provides a single, unified place to configure all your debugging setups \u2013 local, remote, and embedded. Whether you\u2019re using GDB, LLDB, SEGGER J-Link, or ST-Link, everything will live in one place, significantly simplifying the debugger configuration process.<\/p>\n\n\n\n Help us ensure the debugger offers a UX that works for you by participating in this survey<\/a>.<\/p>\n\n\n\n When inspecting a suspended program during debugging, only local variables are automatically tracked and displayed in the Threads & Variables<\/em> pane<\/a>. To see fields (class member variables) or global variables used in functions, you need to set up watches<\/a> for them. However, for some users, fields or global variables may be just as important as local ones, and automatically adding them to the variable list would reduce manual work.<\/p>\n\n\n\n To accommodate this workflow, we\u2019re adding a new option in the Debugger<\/em> settings. It will allow the debugger to automatically display fields and global variables in the Threads & Variables<\/em> pane, while still keeping them distinct from local variables. We plan to introduce this in one of the upcoming EAP<\/a> builds and would love to get your feedback once it\u2019s available (CPP-4992<\/a>).<\/p>\n\n\n\n CLion lets you run multiple debug sessions<\/a>, either sequentially or in parallel. Currently, breakpoints are global, so you cannot assign them to a specific debug configuration. This can be a limitation when debugging multi-process systems or multiple tests. We plan to add configuration-specific breakpoints in the next release (CPP-34455<\/a>).<\/p>\n\n\n\n In 2026.2, we\u2019ll deliver a range of updates to build tools and project formats, including a better Project<\/em> tool window experience for external sources, a refactoring to make it easier to rename CMake targets, expanded Bazel plugin support, and updated bundled toolchains.<\/p>\n\n\n\n When working with source files or folders outside of your root project, the IDE displays them in the same folder as your root project sources in the Project<\/em><\/a> tool window. This works fine if all the sources have unique names. However, when external sources share names with project root sources and their paths are long, it can be difficult to distinguish between them. This is often the case for embedded developers working on projects that require external libraries and files, like Zephyr ones. For the next release, we plan to add a separate node to group all external sources, making it easier to distinguish them from internal sources.<\/p>\n\n\n\n CMake targets are executables, libraries, and utilities created with commands such as We plan to expand support for configuration transitions introduced<\/a> in the previous release:<\/p>\n\n\n\n <\/p>\n\n\n\n We also plan to fix the build options inconsistency caused by hardcoded flag injection in the plugin (see the corresponding GitHub issue<\/a> for more details).<\/p>\n\n\n\n We\u2019ll update some tools shipped with CLion, including:<\/p>\n\n\n\n <\/p>\n\n\n\n CMake 2.8 support will be deprecated.<\/p>\n\n\n\n Embedded developers can look forward to two major improvements in 2026.2: a more flexible way to manage multiple Zephyr West build configurations and extended support for live watches.<\/p>\n\n\n\n We want to make it easier to manage multiple West build configurations that have different build parameters or target different boards. To this end, we\u2019ll add the ability to create configuration profiles for Zephyr West projects<\/a>, similar to CMake profiles (CPP-42799<\/a>).<\/p>\n\n\n\nDebugger<\/h2>\n\n\n\n
Simplified debugger configuration<\/h3>\n\n\n\n
Easier inspection of fields and global variables<\/h3>\n\n\n\n
Configuration-specific breakpoints<\/h3>\n\n\n\n
Build tools and project formats<\/h2>\n\n\n\n
Better UI for external sources in the Project<\/em> tool window<\/h3>\n\n\n\n
![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2026\/04\/External-sources-final.png\")
<\/figure>\n\n\n\nEasier CMake target renaming<\/h3>\n\n\n\n
add_executable<\/code> or add_library<\/code>. Currently, when you need to rename a target in CLion, you have to manually edit all its occurrences. We plan to add a refactoring operation that automatically updates all definitions and usages of a target name across your CMakeLists.txt<\/code> files.<\/p>\n\n\n\nImprovements to the Bazel for CLion plugin<\/h3>\n\n\n\n
\n
Bundled toolchain updates<\/h3>\n\n\n\n
\n
Embedded development<\/h2>\n\n\n\n
Support for using multiple Zephyr West profiles<\/h3>\n\n\n\n
Improvements to live watches<\/h3>\n\n\n\n