[develop2] CMAKE_CONFIGURATION_TYPES with custom build types not getting dependencies added properly

[contre]

We have a project that we are converting from vcxproj to CMake. To ease this transition, we are utilizing the Visual Studio Generator and replacing the default configurations with our own list to match what we had in the vcxproj before. This consists of Debug, Release, DebugTests, and ReleaseTests. We are defining these by curating the list of available build types in the CMAKE_CONFIGURATION_TYPES variable.

I understand this isn't really the CMake way of handling tests but, as I said above, I'm trying to ease us into this transition by keeping things as familiar as possible for our Devs.

However, with the cmake-conan integration, I've run into a situation where an included dependency is being properly added to the generated vcxproj for the Debug and Release configurations but not for our DebugTests and ReleaseTests configuration. Specifically, I'm not seeing any of our included packages being included in the AdditionalDependencies and AdditionalLibraryDirectories parts of the generated vcxproj.

I'm not sure if this is a bug or simply me doing something wrong as I'm new to conan and new to defining custom build types for CMake.

We're targeting VS2019 toolset, conan2, and CMake 3.27.

I do not, at the time of this reporting, have a minimal repro available but I will spend some time on one, if needed.

[memsharded]

Hi @contre

Thanks for your question.

However, with the cmake-conan integration, I've run into a situation where an included dependency is being properly added to the generated vcxproj for the Debug and Release configurations but not for our DebugTests and ReleaseTests configuration. Specifically, I'm not seeing any of our included packages being included in the AdditionalDependencies and AdditionalLibraryDirectories parts of the generated vcxproj.

At the moment, the conan_provider.cmake just does a repeated call for build_type=Release and build_type=Debug: https://github.com/conan-io/cmake-conan/blob/82284c0204e87f36c7d5706bf2963bae735904a4/conan_provider.cmake#L568

Maybe the solution is to do there another calls for different configurations? It depends on how your CMake custom configurations are mapped to Conan configuration/profiles. Is it a Conan option, a Conan conf to control the tests? The default conan one is tools.build:skip_test that can inhibit the building and execution of tests in built-in integrations. There are different controls for custom configurations like for CMakeDeps: https://docs.conan.io/2/reference/tools/cmake/cmakedeps.html#configuration.

Not necessary a repro at the moment, but better understanding the custom configurations would help, we can leave the repro for later if still necessary. Thanks!

[contre]

Likely the real solution here would be to adapt to the CMake and conan way of defining whether tests are built or not.

So I'll just go ahead and make use of CMakePresets and define drop down options for people that just build debug/release and set the necessary flags for enabling or disabling tests. I was mostly just trying to avoid having to teach people how to use the CMake mode of Visual Studio and instead be able to work off of generated projects if they wanted to.

Thanks for pointing me in the right direction to gain some understanding.

[memsharded]

Likely the real solution here would be to adapt to the CMake and conan way of defining whether tests are built or not.

Sounds good. Conan would be pretty flexible and might allow to use custom configurations as you wanted, see for example this test if it serves as inspiration: https://github.com/conan-io/conan/blob/f0bddeb301cdeb96598b3291cc93b2d433e38ca6/conans/test/functional/toolchains/cmake/cmakedeps/test_cmakedeps_custom_configs.py#L36. But I agree that something more aligned with CMake and Conan standard practices sounds good.

Thanks for pointing me in the right direction to gain some understanding.

Happy to help, don't hesitate to open new tickets for any further question that you might have. Thanks for the feedback!