Confusion Regarding Conan and Multi-Config Generator

[FlyAndNotDown]

For multi-config generators (such as Ninja multi-config, Visual Studio), should Conan run install once with -s &:build_type=xxx for each config that the user might use?

As far as I know, -s build_type is used to specify the config for installing dependencies, and -s &:build_type is used to specify the config for the project. The Conan CMakeDeps generator will generate the corresponding xxx-Target-xxconfig.cmake based on -s &:build_type for finding libraries.

Multi-config generators do not explicitly specify the config when configuring the project, but rather specify the config at build time, so Conan should prepare the CMake files for finding libraries for all possible configs that might be used.

Currently, I have made some temporary modifications in my project to solve this problem:

# conan_provider.cmake
foreach(_build_config IN LISTS _build_configs)
    set(_self_build_config "")
    if(NOT _multiconfig_generator AND NOT _build_config STREQUAL "${CMAKE_BUILD_TYPE}")
        set(_self_build_config -s &:build_type=${CMAKE_BUILD_TYPE})
    endif()
    # ++
    if(DEFINED CONAN_INSTALL_SELF_CONFIGURATIONS)
        foreach(_self_config ${CONAN_INSTALL_SELF_CONFIGURATIONS})
            conan_install(${_host_profile_flags} ${_build_profile_flags} -s build_type=${_build_config} -s &:build_type=${_self_config} ${CONAN_INSTALL_ARGS} ${generator})
        endforeach()
    else()
        conan_install(${_host_profile_flags} ${_build_profile_flags} -s build_type=${_build_config} ${_self_build_config} ${CONAN_INSTALL_ARGS} ${generator})
    endif()
    # --
endforeach()

# project cmake
set(CONAN_INSTALL_BUILD_CONFIGURATIONS "Release" CACHE STRING "" FORCE)
if (${generator_is_multi_config})
    set(CONAN_INSTALL_SELF_CONFIGURATIONS ${CMAKE_CONFIGURATION_TYPES} CACHE STRING "" FORCE)
else ()
    set(CONAN_INSTALL_SELF_CONFIGURATIONS ${CMAKE_BUILD_TYPE} CACHE STRING "" FORCE)
endif ()
set(CMAKE_PROJECT_TOP_LEVEL_INCLUDES ${CMAKE_SOURCE_DIR}/conan_provider.cmake CACHE PATH "" FORCE)

If not modified this way, Conan will only generate the corresponding CMake files based on the install configuration. For example, if I set CONAN_INSTALL_BUILD_CONFIGURATIONS to Release, but use RelWithDebInfo config for building, the dependency libraries will not be found. This is because Conan only generates xxx-Target-Release.cmake to locate the libraries. More critically, all related target properties are wrapped with generator expressions like $<$<CONFIG:Release>:xxx>. Even if you try to use CMAKE_MAP_IMPORTED_CONFIG for remapping, it won’t work because CMAKE_MAP_IMPORTED_CONFIG is ineffective against generator expressions.

I wonder why the official Conan-provided conan_provider.cmake does not handle this case?

[jcar87]

if I set CONAN_INSTALL_BUILD_CONFIGURATIONS to Release

. This is because Conan only generates xxx-Target-Release.cmake to locate the libraries.

In this case conan was invoked to generate exactly what you asked it to generate.
If you know you are going to be using the RelWithDebInfo configuration - just add it to CONAN_INSTALL_BUILD_CONFIGURATIONS that is, it could have Release;RelWithDebInfo;Debug as a valid value.

[FlyAndNotDown]

if I set CONAN_INSTALL_BUILD_CONFIGURATIONS to Release

. This is because Conan only generates xxx-Target-Release.cmake to locate the libraries.

In this case conan was invoked to generate exactly what you asked it to generate.
If you know you are going to be using the RelWithDebInfo configuration - just add it to CONAN_INSTALL_BUILD_CONFIGURATIONS that is, it could have Release;RelWithDebInfo;Debug as a valid value.

But sometimes users need to split 3rd-party install config and project build config. Like I want to use release 3rd-party install config for all project build configs. In this case, your solution is not work I think.

I think it is necessary to add a new variable to manage project configs rather than just use CONAN_INSTALL_BUILD_CONFIGURATIONS.

[memsharded]

But sometimes users need to split 3rd-party install config and project build config. Like I want to use release 3rd-party install config for all project build configs. In this case, your solution is not work I think.

This is not clear, why it wouldn't work?
This is exactly what this variable is doing, installing dependencies for those configurations, and that is separate and independent of the consumer project configurations.

If things are not working as expected, it would be necessary to have clear and detailed reproduction steps, with a minimal setup:

• a minimal CMakeLists.txt and source .cpp files (if necessary, the .cpp files might be unnecessary for some cases)
• the exact commands you are using that produce and illustrate the errors
• The full output of the commands, including those errors

Thanks for the feedback.

[FlyAndNotDown]

But sometimes users need to split 3rd-party install config and project build config. Like I want to use release 3rd-party install config for all project build configs. In this case, your solution is not work I think.

This is not clear, why it wouldn't work? This is exactly what this variable is doing, installing dependencies for those configurations, and that is separate and independent of the consumer project configurations.

If things are not working as expected, it would be necessary to have clear and detailed reproduction steps, with a minimal setup:

• a minimal CMakeLists.txt and source .cpp files (if necessary, the .cpp files might be unnecessary for some cases)
• the exact commands you are using that produce and illustrate the errors
• The full output of the commands, including those errors

Thanks for the feedback.

Project structure:

root
- CMakeLists.txt
- conan_provider.cmake
- conanfile.txt
- main.cpp

CMakeLists.txt:

cmake_minimum_required(VERSION 4.0)

set(CONAN_INSTALL_BUILD_CONFIGURATIONS "Release" CACHE STRING "" FORCE)
set(CMAKE_PROJECT_TOP_LEVEL_INCLUDES ${CMAKE_SOURCE_DIR}/conan_provider.cmake CACHE PATH "" FORCE)

project(conan_test)

set(CMAKE_CXX_STANDARD 20)

find_package(GTest REQUIRED GLOBAL)

add_executable(conan_test main.cpp)
target_link_libraries(conan_test GTest::gtest)

conanfile.txt:

[requires]
gtest/1.17.0

[generators]
CMakeDeps

main.cpp:

#include <iostream>
#include <gtest/gtest.h>

TEST(SimpleTestSuite, SimpleTest)
{
    ASSERT_EQ(1, 1);
}

int main()
{
    return RUN_ALL_TESTS();
}

CMake configure commands:

cmake -S . -B build -G "Visual Studio 17 2022"

Build commands:

 # failed, can not find gtest lib
cmake --build build --config Debug
cmake --build build --config RelWithDebInfo
cmake --build build --config MinSizeRel
# success
cmake --build build --config Release

I understand you might suggest setting CONAN_INSTALL_BUILD_CONFIGURATIONS to Debug;Release;RelWithDebInfo;MinSizeRel. However, I want to emphasize that in scenarios where users need to always link to release versions of third-party libraries regardless of the build configuration, this approach becomes ineffective. More critically, based on my observations, conan packages that do not use CMake as their build system​ (like Mysys + Makefile on Windows) may fail to compile under specialized configurations like RelWithDebInfo or MinSizeRel.

[memsharded]

Thanks for the details to reproduce, that helps to understand it.
It seems you are missing in your CMakeLists.txt:

set(CMAKE_MAP_IMPORTED_CONFIG_RELWITHDEBINFO Release)
...

This is likely it won't be necessary with the new incubating CMakeConfigDeps generator, but at the moment the mapping is necessary.

I hope this helps.