[suggest][dev2] Run conan install and include conan_toolchain.cmake directly when injection.

[hwhsu1231]

Suggestion

According to https://github.com/conan-io/cmake-conan/issues/475#issuecomment-1465143238

Since the conan install command is executed in the conan_provide_dependency() function, the conan_toolchain.cmake file of CMakeToolchain will be generated only when the find_package() command is called, which is after the project() command. Therefore, the CAE problem cannot be solved.

However, I suddenly thought of an idea:

1. _What if we run conan install and include conan_toolchain.cmake directly when injection._
2. _And then append ${CONAN_GENERATORS_FOLDER} into CMAKE_PREFIX_PATH inside conan_provide_dependency()_.

In other words:

[DEBUG] Before calling "project()" command...
[DEBUG] Start to include "conan_provider.cmake" file...        # run conan install and include conan_toolchain.cmake
[DEBUG] After calling "project()" command...
[DEBUG] Before calling "find_package(fmt)" command...
[DEBUG] Start to call "conan_provide_dependency()" function... # append ${CONAN_GENERATORS_FOLDER} into CMAKE_PREFIX_PATH
[DEBUG] After calling "find_package(fmt)" command...

Maybe the CAE problem can be solved in this way?

[memsharded]

Hi @hwhsu1231

I am afraid that what you are suggesting is not possible:

DEBUG] Before calling "project()" command... [DEBUG] Start to include "conan_provider.cmake" file... # run conan install and include conan_toolchain.cmake

You need the full CMake definition of compiler to be able to obtain it and use it for conan install. Until CMake don't fully define the setup, it is not possible to get the values, and that doesn't happen until after the project()

[hwhsu1231]

@memsharded

If that is the case, I feel like we might have reached a deadlock with Dependecny Provider. Any other ideas?

[memsharded]

No we havent, this is good. This can work by guaranteeing an alignment between the configuration and what would be generated by the conan_toolchain.cmake. If the detection of the current configuration is good enough, and it would match the generated conan_toolchain.cmake, we will be good.

The plan is now to test it, experiment with it and get feedback, and lets see how it goes. So far it seems it has good potential.

[hwhsu1231]

This can work by guaranteeing an alignment between the configuration and what would be generated by the conan_toolchain.cmake. If the detection of the current configuration is good enough, and it would match the generated conan_toolchain.cmake, we will be good.

What do you mean? Do you mean that we won't need CMakeToolchain anymore in the future?

[memsharded]

It is definitely needed for building packages, because the cmake-conan integration is only for pure consumers, but cannot and will never be used to create packages.

It will also be very relevant in many other situations and contexts. The vast majority of Conan users are not using the cmake-conan integration, and there will be some special scenarios like when having tool_requires that cannot work with cmake-conan by definition.

[hwhsu1231]

It is definitely needed for building packages, because the cmake-conan integration is only for pure consumers, but cannot and will never be used to create packages.

So you mean that CMakeToolchain is:

• required when creating the package,
• but not so important when consuming the package.

Therefore, it's fine to use just CMakeDeps with cmake-conan in most cases, right?