[question] Limitations of CMakeToolchain wrt legacy generators

[rconde01]

What is your question?

I am migrating from a v1 based configuration where I was using the cmake generator. Using this configuration I had multiple consumer conanfiles using different profiles which different parts of the build tree used. In migrating to conan v2 and CMakeToolchain I've just realized this is not possible anymore since the toolchain is passed to the root. It appears that ExternalProject_Add is a partial workaround in that it allows multiple toolchains, but in the IDE (Visual Studio) it only shows the ExternalProject as a target - not the subtargets.

I'm not saying there's anything wrong with Conan here, but just providing a scenario where as a package consumer I don't see a path to accomplish what I want. If it's a reasonably common case maybe you want to brainstorm solutions - or perhaps just list it as a limitation in the docs.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[rconde01]

Hmm...I wonder the disadvantage of include(conan_toolchain.cmake) rather than specifying on the command line?

[rconde01]

it doesn't work - it seems like the targets don't get updated after the first definition

[memsharded]

The include(conan_toolchain.cmake) definitely doesn't work if it is added after project() call. In some scenarios it might work if passed before project() call, but I think even in those cases the net effect is still not identical to passing it explicitly as a CMAKE_TOOLCHAIN_FILE argument, as toolchains have some special meaning to CMake.

I'm not saying there's anything wrong with Conan here, but just providing a scenario where as a package consumer I don't see a path to accomplish what I want. If it's a reasonably common case maybe you want to brainstorm solutions - or perhaps just list it as a limitation in the docs.

Yes, this is a result of the majority of users complaining about Conan being intrusive and demanding a transparent integration, that basically needs to use a CMake toolchain.

I agree this is something that we want to at least think about it. It is also quite close to the "workspace" feature (check #15992), it shares the same challenges.

[rconde01]

Yes, this is a result of the majority of users complaining about Conan being intrusive and demanding a transparent integration, that basically needs to use a CMake toolchain.

At a high level I get the sentiment, but if you consider custom packages I think changing some references in your CMakeLists.txt is a pretty small part of migration to some other package manager (which I assume is the motivation for transparent integration)? But maybe I'm missing something, and if "the crowd demands it" I guess it doesn't matter anyhow.