[question] Limitations of `CMakeToolchain` wrt legacy generators about conan HOT 4 OPEN

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.

from conan.

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

from conan.

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

from conan.

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.

from conan.