Conan 2.x CLion Migration Questions

[radonish]

Hello,

I'm working on migrating my company to Conan 2.x. I have our packages now building across many profiles by using Conan on the command line (via conan create both manually and in Jenkins pipelines).

Now I am trying to get the packages/projects to build within CLion. For Conan 1.x we are using CLion 2022/Conan 1.66.0/Conan Plugin 1.x. For Conan 2.x we are using CLion 2023/Conan 2.10.0/Conan Plugin 2.0.6. Initial problems I see:

1. I'm not seeing how I can reference a tool_requires() dependency (which essentially just pulls in a utility CMake file our CMakeLists.txt includes)
2. When I temporarily ignore problem 1. above by commenting out the inclusion of our utility CMake file, CLion is able to load the CMakeLists.txt (which contains find_package() calls for other Conan packages per the Conan 2.x convention) but when I attempt to build it fails to find the header files of those dependencies.

The CMakeLists.txt is pretty simple; here's an example template:

cmake_minimum_required(VERSION 3.24)
project(libx)

add_library(libx <source file list>)

find_package(liba REQUIRED CONFIG)
find_package(libb REQUIRED CONFIG)

target_include_directories(libx PUBLIC include)
target_link_libraries(libx liba::liba libb::libb)

In this example, liba and libb are other internal libraries that are specified in libx's conanfile.py as requirements. I built them manually and are in my local Conan package cache.

I read over the documentation for the CLion Conan plugin and not seeing what I am missing.

Any help would be appreciated. Thank you!

[czoido]

Hi @radonish,

Thanks a lot for your question.

For the first part, doing that should be possible, add the package as a tool_require to your consumer conanfile.py and then you can require your CMake scripts from the consumer, maybe this part of the docs can help you: https://docs.conan.io/2/examples/graph/tool_requires/use_cmake_modules.html

For the second, I'm not sure what could be happening. Could you please share part of the logs you are getting? Have you tried with a simple project including some library like fmt or something similar following the instructions from the docs? https://docs.conan.io/2/integrations/clion.html

[radonish]

Hello @czoido, thanks for your response.

For question 1, your guidance helped a lot - I updated the producer and consumer conanfile.py files as directed in that link and all worked exactly as needed.

For question 2, I stumbled into something that successfully built but I'm trying to understand how it translates to our use case. What gave me a successful build was switching the CMake profile being used from a pre-existing one I used for Conan 1.x to one that the plugin created.

The plugin created 2 CMake profiles apparently: "conan-release" and "conan-release conan-release". The only difference I see is that the "conan-release" profile has --preset "conan-release" under "CMake options" while the "conan-release conan-release" profile has that same "CMake options" value but also has --preset "conan-release" under "Build options". Was the 2nd profile created in error? The naming is a bit quirky.

My pre-existing profile was automatically updated by the Conan plugin which is what led me to believe it would just work. It updated my profile to have "CMake options" -G "Unix Makefiles" -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES="conan_provider.cmake" -DCONAN_COMMAND="/path/to/conan". I then added -DCONAN_HOST_PROFILE and -DCONAN_BUILD_PROFILE. But, as noted in my original post, when I attempt to build it cannot find the header files of the installed dependencies. So, there appears to be something missing in the "CMake options" of my pre-existing profile that are there for the Conan Plugin-created CMake profiles.

Backing up a bit, the end goal is to get a similar experience to Conan 1.x/Conan Plugin 1.x in that I had CMake profiles for different Conan profiles (e.g. profile-x86_64-release, profile-x86_64-debug, profile-aarch64-release, profile-aarch64-debug, etc). The old plugin would pop up a window that made you map CLion CMake profiles to Conan profiles - I liked that. I'm just trying to accomplish the same thing now so developers on my team can ensure projects build for different profiles within the IDE. It looks like the integration docs assume you're just using default debug/release profiles so some guidance as to how to correctly map CMake profiles to Conan profiles would be very helpful.

Thanks!

[radonish]

Following up, I started over (recreated the CLion toolchain and CLion CMake profile) with the Conan 1.x/Conan Plugin 1.x pre-existing CMake profile and now it is correctly finding header files for the dependencies. It appears to have been in a funny state.

I am still interested in feedback as to the preferred/right way to use CLion with various Conan profiles. Right now I am doing this:

1. Settings->Build, Execution, Deployment->Toolchains: Add new toolchain by giving it a name that matches a Conan profile filename for clarity, updating the C compiler path, and updating the C++ compiler path
2. Settings->Build, Execution, Deployment->CMake: Add new CMake profile selecting the toolchain I just created, choosing either Release/Debug, hitting OK
3. Conan Plugin->Configure Conan: Ensuring the newly created CMake profile is selected under "Use Conan for the following configurations"
4. Conan Plugin->Update packages and dependency provider
5. CMake view->Click desired CMake profile tab->Reload CMake Project
6. Settings->Build, Execution, Deployment->CMake: Update CMake profile to have -DCONAN_HOST_PROFILE and -DCONAN_BUILD_PROFILE
7. CMake view->Click desired CMake profile tab->Reload CMake Project

If I follow those steps I am able to successfully load the CMakeLists.txt and build for the different profiles. Is this what you envisioned for working with existing Conan profiles? Is there a better way that I am missing?

Thank you!