We’re launching the Early Access Program for CLion 2019.2! As usual, the EAP builds are free to use and no license is required. Get early access to the upcoming changes and enhancements and give us your feedback! We want to test it in all kinds of non-standard or unusual environments you may have set up, and collect and fix as many issues and regressions as possible. So, please try these builds and let us know what you think!

Note you can install any EAP build in parallel with a stable CLion release such as 2019.1.

As usual, you can download build 192.4205.36 from our site by using the Toolbox App, or by using a snap package (if you are using Ubuntu).

More and more C++ events, community meetups, and conferences are appearing around the globe. 2019 is definitely looking like a year for new C++ conferences. Take, for example, C++ on Sea (UK, in February) or the upcoming CPPP (France, in June). Even C++ Russia now has two editions per year – one in Moscow and one in St. Petersburg. And, finally, there’s the event we just visited – Core C++, held in Tel Aviv, Israel.

Core C++ was started by the organizers of two big local communities, the Core C++ meetup in Te Aviv and the Haifa::C++ meetup. Adi Shavit from Tel Aviv is a well-known international speaker you may have met at one of the many C++ events around the world. The event was hosted at the Academic College of Tel Aviv–Yaffo, very close to the beautiful and historic old city of Jaffa.

Wondering how to add a package to your C++ project? In this guest blog post Javier G. Sogo from JFrog shares how to start with Conan package manager in CLion.

Javier G. Sogo@jgsogo
Software Engineer at JFrog
After several years of C++ development, I moved to Python to learn the best practices and tools. Now I’m back building Conan, the C/C++ package manager.

Writing a C++ project from scratch is always a delightful challenge. Starting from a blank page writing your code and creating your functionalities, all the way through to building on top of solid and high-performance libraries… but wait! Sometimes it’s not easy to get those libraries available for your project to compile and link, and possibly you are not experienced in that build system or the library may require some patches to be built for your platform.
The lack of a package manager in the C++ world has slowed many projects down, requiring dedicated efforts to handling external libraries or rewriting functionalities to avoid using third parties.Conan is an open source, decentralized package manager that simplifies the process of integrating and reusing C and C++ libraries and packages. It automatically manages and reuses binaries for any possible configuration, increasing development speed. Conan is also able to build and cross-build packages from sources, it integrates with any build system, with very high flexibility and customization capabilities.
In this blog post, we will show how to use Conan in your CLion workspace to get your preferred libraries ready to use in your project. We will use the Conan-CLion plugin to integrate both applications smoothly, for example, by building an MD5 hasher using an already available implementation from the Poco libraries.

Installing all the parts

1. Conan-CLion Plugin

To follow along with this example, you’ll need to install the Conan by JFrog plugin from the JetBrains marketplace. It can be easily installed using the Plugins section in the Preferences/Settings window, or from the welcome screen using the Configure>Plugins option.

After restarting CLion a new “Conan” tool window will appear at the bottom of the IDE, which is ready for you to use.

2. Conan Client

Next, you’ll need to install Conan. Conan is a python application, you can install it using pip (pip install conan) inside a Python virtual environment or system-wide, or you can download a standalone application and unpack it into your system, choose the way that best fits your needs from the download page.
We highly recommend that you read the Conan documentation; although the default configuration is enough for this example, it is important for you to know about many other important features that are not covered in this article. Including, the distributed nature of Conan that allows mixing different origins for your libraries, JFrog Artifactory integrations, workspaces, etc. These features will help you in developing high-quality software.

3. Conan Plugin Configuration

There are a couple of configuration points we need to address before running our example, these configurations only need to be done once for all your projects. First of all, you will need to provide the path to the Conan executable you want to use in the Preferences window (leave it empty to use Conan from the PATH).

Second, we need to define the correspondence between CLion CMake profiles and Conan profiles. CLion profiles are a handy way to create different configurations to build your project, the same as Conan profiles, that’s why both should match.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

[settings]

os=Macos

os_build=Macos

arch=x86_64

arch_build=x86_64

compiler=apple-clang

compiler.version=10.0

compiler.libcxx=libc++

compiler.cppstd=gnu17

build_type=Release

[options]

zlib:shared=False

[build_requires]

cmake_installer/3.13.0@conan/stable

[env]

A Conan profile is a file where the user defines a set of settings, options, environment variables, and build requires, that can be reused to build any package. These files can be handled individually using conan profile commands or, if you are working with other people, you will probably want to maintain a shared configuration with your colleagues using conan config install commands. Create as many profiles as you want using the command line or copy an URL with your shared Conan configuration into the plugin settings. For more information related to this core feature of Conan, the documentation about using profiles is a good starting point.
Once your profiles are ready, match them with the CLion ones using the button, a window will pop up for you to make these assignments.

If we try to compile this project using CLion it will fail, because the Poco libraries are missing. This is where our package manager comes into action.

Getting your dependencies with Conan

Conan uses a separated file to store information related to a project. This can either be a plain conanfile.txt file, or a python conanfile.py file that handles more complex logic regarding your dependencies. The Conan plugin can work with both of these file types.
For this example we only need a couple of lines in a conanfile.txt that you should add to your repository:

1

2

3

4

5

[requires]

Poco/1.9.0@pocoproject/stable

[generators]

cmake

[requires]

These lines notify Conan that our project requires the Poco library, and provide the version and origin for it. Conan will look in the remotes and retrieve the recipe for Poco from there, it will also grab the binaries if they’re available for your configuration and, if not, it will trigger a compilation from sources. All of this will be done using the Conan install button, , that can be found in the Conan tool window.

As you can see, Conan not only installed the Poco libraries, but also OpenSSL and ZLib too. This is because they are transitive dependencies of Poco. If binaries matching your configuration are available in the remote, Conan will just download them, otherwise, Conan will compile these packages from sources no matter if they use CMake or other build systems (OpenSSL uses Makefiles).

[generators]

Conan will create a file for each of the generators listed here, as CLion uses CMake we need that generator. These files contain all the information of the requirements, including: paths to includes, libraries or resources, and compile flags. Basically, everything that needs to be consumed by your project. You only need to include this file into your build system, there is no need to change anything else, and you’re ready to go.
Modify your CMakeLists.txt to include this automatically generated file, named conanbuildinfo.cmake:

1

2

3

4

5

6

7

8

cmake_minimum_required(VERSION2.8.12)

project(MD5Hasher)

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)

conan_basic_setup()

add_executable(md5_hasher main.cpp)

target_link_libraries(md5_hasher${CONAN_LIBS})

Compile again and run your project. Conan will take care of your dependencies, by locating and downloading (or compiling) them, making them available for your project. If you feel that this implementation requires modifying your project, you can try other CMake related generators available in Conan, such as cmake_find_package or cmake_paths. Additional information on how to activate these generators can be found in the Conan documentation.

Conclusion

Alongside CMake and CLion, Conan has become one of the big C’s for the C++ language. Having a package manager encourages the community to share their libraries and build functionalities on top of existing ones, modernizing the C++ ecosystem towards a more mature and useful one. It also allows companies to have a professional tool to build all their internal libraries and third-parties using the same process, preserving consistency and reproducibility of their builds, and keeping their developers focused on their job.
The plugin in its first version implements just some basic functionalities of Conan, we highly recommend you to use it in your projects, but also to explore all the functionalities that Conan provides. We’re always happy to receive feedback related to both the CLion plugin and Conan in general.

Please welcome a new bug-fix update: CLion 2019.1.3! Build 191.7141.37 is now available to download from our website, via the Toolbox App, or via snap (for Ubuntu). A patch-update will be available shortly.

A few days ago we published the first bug-fix update (2019.1.1) for the recently released CLion 2019.1. Thanks to our vigilant users, we’ve learned quickly that this build is affected by a very unpleasant freeze on IDE start when several projects are opened (CPP-16039, OC-18440). The IDE fails to recover in that case, unfortunately.

We are sincerely sorry for this and apologize for any inconvenience it might have caused. We’ve analyzed the source of the issue and will do our best to prevent such situations in the future.

If you are using v2019.1 (and especially 2019.1.1), we recommend that you update to the newest 2019.1.2 build, which is now publicly available. Download it from our website, via the Toolbox App, or via snap (for Ubuntu). A patch-update will be available shortly.

With CLion 2019.1 released just a couple of weeks ago, it’s already time for the first bug-fix update. Build 191.6707.62 is now available to download from our website, via the Toolbox App, or via snap (for Ubuntu). A patch-update will be available shortly.

In the newly added naming convention settings (Settings/Preferences | Editor | Code Style | C/C++ | Naming Convention), Upper_Snake_Case is now available as one of the options.

Bundled CMake was updated to v3.14.2.

Custom build targets and run/debug configuration are useful for compilation database projects, especially when using them to workaround Makefiles and other project models not natively supported in CLion. In this update we made the configuration process even more friendly – CLion now allows you to configure Custom Build Target right from the Run/Debug configuration settings dialog:

We’ve recently just released CLion 2019.1! It has been served up with several major improvements, like Clangd-based code highlighting, integration with ClangFormat, project-model-independent build targets and run/debug configurations (especially useful for compilation database and Makefiles projects), memory view in the debugger, injected languages, and not to forget of course some initial Embedded Development support. Release time is always exciting, and we are enormously inspired by all your positive feedback and kind words!

There are still a couple of glitches and regressions, but we are planning to sort them out with the first bug-fix update. Right now, it feels like a good time to give our sincerest thanks to the most active evaluators and share with you all our plans for v2019.2.Continue reading →

Please note that to use CLion 2019.1 RC, you need to have an active subscription (or start a 30-day evaluation period). No patches are provided for this release candidate, but you can expect a patch from the latest 2018.3.4 update to the 2019.1 release version.

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). Previously, we’ve triggered the synchronization of the header search paths on every CMake reload, which might be a time-consuming task. Now 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 to the previous one, if you still prefer it.

Besides that, this RC delivers the following fixes and changes:

Clangd memory indicator is now turned off by default and can be enabled along with the JVM memory indicator in Settings/Preferences | Appearance & Behavior | Appearance | Windows Options | Show memory indicator.

When MinGW is used in CLion, user input is no longer duplicated in the output window (CPP-2580). Unfortunately, the issue is still present for WSL and Remote toolchain cases (CPP-15753).

CLion 2019.1 goes Beta! To install CLion 2019.1 Beta (build 191.6183.6), download it from the website, update from our Toolbox App, or through a snap package (if you are using Ubuntu), or use a patch update.

The Beta builds are sufficiently stable compared to the EAP builds, but some issues may still occur. If they do for you, please report them to our issue tracker. No license is required to use this build.