Conan: [question] Why doesn't conanbuildinfo.cmake actually invoke conan_basic_setup() itself?

[michaelmaguire]

Apologies if this has already been asked and an answer already provided elsewhere.

My understanding of CMake is that a file such as our current conanbuildinfo.cmake could just include a call to conan_basic_setup() at the end of the file, after the macro has been defined.
Is there a reason we don't do this?

Not only would this simplify the changes needed to include conan support in a CMakeLists.txt, but it might also facilitate some of our experiments with non-invasive cmake inclusion using, e.g. https://cmake.org/cmake/help/latest/command/project.html#code-injection

• [x] I've read the CONTRIBUTING guide.

[memsharded]

Hi @michaelmaguire

Yes, this is a design policy, that we have tried hard to carefully respect since the very first version of Conan: Never block the user, and allow the user to customize the Conan proposed defaults.

If including conanbuildinfo.cmake automatically calls conan_basic_setup(), then all users are forced to use whatever defaults are used in that call:

conan_basic_setup() can be called with different arguments: TARGETS for creating modern cmake targets, or NO_OUTPUT_DIRS if you don't want Conan to modify the bin/lib output directories, just as 2 examples.

Also, another very typical case is to manipulate some of the variables before:

include(..../conanbuildinfo.cmake)
# Do a filter of some CONAN_LIBS variable, to remove some unnecessary libs
conan_basic_setup()

As you can see, these heavily used features will be totally impossible if one-step inclusion+activation.

Trying to improve the integration and being less intrusive, we are trying to evolve in different directions, like the new cmake_find_package_multi generators, or the ongoing work with the definition of toolchains in the recipes.

[michaelmaguire]

Thanks for the explanation!