Using multiple Conan profiles in CLion

[radonish]

Background:
We have 5 different targets and thus 5 different toolchains to build SW for those targets. There are 2 Conan profiles for each toolchain - 1 debug and 1 release. Thus, we have a total of 10 Conan profiles and would like to build for any of those profiles within CLion. My CLion CMake configuration looks like this:

The CMake profiles reference the configured toolchains:

Issue:
I'm trying to find the "right way" to pull in Conan profiles within CLion so settings within the profile (e.g. CXXFLAGS, LDFLAGS) get used when building.

Setting CONAN_HOST_PROFILE and CONAN_BUILD_PROFILE in the CLion CMake options ensures that the right packages get pulled in but does not impact the CXXFLAGS/LDFLAGS being used.

I noticed CMakeUserPresets.json files getting created at the project root and that they contained references to CMakePresets.json files for each profile that has ever been enabled:

I updated one of the CMake profiles in the CLion configuration to additionally have the --preset conan-debug parameter as I saw that is the preset name automatically generated (by this plugin?). Since there are more than 1 CMakePresets.json files included, there are multiple definitions of the "conan-debug" preset. This results in a "Duplicate preset: conan-debug" error. If I remove one of the preset includes manually, I can use the --preset conan-debug parameter and the Conan profile's CXXFLAGS/LDFLAGS get used (by way of the generated Conan toolchain file).

Question:
Is the intention for users to use the --preset parameter to pull Conan profile settings in? Or should CMAKE_TOOLCHAIN_FILE be used directly somehow?

Also, if the plugin is generating the CMakePresets.json file, could it be updated to use unique names to avoid the multiple "conan-debug" name conflict? Perhaps they could use part of the CMake profile name?

Thanks in advance for any help!

[czoido]

Hi @radonish,

Thanks for your question.

The issue is a chicken‑and‑egg situation: the plugin calls cmake‑conan internally. When you enable preset generation in your conanfile.py (tc.user_presets_path is False by default), CLion does discover those presets, but every time cmake‑conan runs conan install, it regenerates the same files, so CLion sees them constantly overwritten and fails to use them reliably.

If you want to depend on the presets produced by Conan, I think the best way is to handle the conan calls yourself instead of delegating them to cmake‑conan:

1. In the Conan Plugin settings uncheck Automatically add Conan support for all configurations, and make sure it's also unchecked for every individual CMake profile (see attached screenshot).

2. Invoke Conan manually instead of letting cmake‑conan do it, e.g.:

   conan install . --pr:h=<your-profile>

   This generates CMakePresets.json (and CMakeUserPresets.json) with the correct buildenv variables from the profile.

3. Go to CMake profiles in CLion configuration and enable those presets.

From that point on, you can build normally in CLion, and the environment variables from your Conan profile will be set via the presets.

Hope this helps!

[radonish]

Hello, @czoido - thanks for your response.

If you want to depend on the presets produced by Conan

I'm just looking for the best/right solution - no preference for presets. I'd say that a desirement is to minimize actions required by my developers when using CLion. So, having them manually invoke Conan is something I'd like to avoid.

Right now, a new developer simply has to do the following to get up and running:

1. conan config install
2. Run CLion
3. Import company CLion settings (define toolchains)
4. Open project (all projects have CMake settings within the .idea/cmake.xml file) - automatically reload CMakeLists.txt
5. Build

I've gone ahead and unchecked Automatically add Conan support for all configurations, and essentially duplicated the CFLAGS/CXXFLAGS/LDFLAGS in the Conan profiles and set CMAKE_C_FLAGS/CMAKE_CXX_FLAGS/CMAKE_SHARED_LINKER_FLAGS. That seems to work well enough. See any issues?

Thanks!