[develop2] Running conan install multiple times to support CMake superbuild / FetchContent workflows

[simfinite]

Hi,
I have a set of projects that heavily rely on CMake's FetchContent module to compose what is sometimes referred to as "superbuilds", i.e. I can retrieve projects on-the-fly and add them to the CMake source tree or I can have them checked out side-by-side in a workspace and have CMake traverse the source directories.

In the past, I have used the Conan v1 CMake integration quite successfully here by calling Conan from CMakeList.txt files of all projects that have external dependencies that could be retrieved via Conan (thanks for the effort put into this project, btw).

With the new approach for Conan v2, conan install is only called exactly once on the root source directory. This seems to be incompatible with my old approach. However, I am wondering if this restriction can be lifted? In fact, I hacked a bit into the conan_provider.cmake script and could get a basic example to work by calling conan install once from each CMAKE_CURRENT_LIST_DIR that is seen by the dependency provider callback macro.

I would appreciate any feedback on the possibility of supporting such a workflow. I would be happy to contribute if this is something worth pursuing.

On a side note: I am aware that another solution would be to just use Conan to resolve dependencies everywhere instead of relying on CMake's FetchContent, however, with the above mentioned projects I would like to stick to a "CMake-first workflow" at least for the near future.

[simfinite]

Investigating further, I stumbled upon a problem regarding values of CMAKE_MSVC_RUNTIME_LIBRARY with this approach that was also discussed here #613:

When building a project with multiple dependencies that are included into the build via FetchContent, the top-level project must include the Conan dependency provider script via CMAKE_PROJECT_TOP_LEVEL_INCLUDES. Consequently, when actually building a Conan package for this top-level project, the dependency provider script must also be passed to the CMake build from the recipe, e.g.:

    def build(self):
        cmake = CMake(self)
        cmake.configure(
            variables={"CMAKE_PROJECT_TOP_LEVEL_INCLUDES": "../conan_provider.cmake"}
        )
        cmake.build()

This actually works quite well, however, the toolchain file generated by CMakeToolchain generator will be used and - as discussed in #614 - this may set values for CMAKE_MSVC_RUNTIME_LIBRARY that are currently not supported by conan_provider.cmake. In particular, I could see these additional values in my builds, but there may be more:

$<$<CONFIG:Release>:MultiThreadedDLL>
$<$<CONFIG:Debug>:MultiThreadedDebugDLL>
$<$<CONFIG:Release>:MultiThreadedDLL>$<$<CONFIG:Debug>:MultiThreadedDebugDLL>