[bug] Using build/host profiles, Conan does not generate (some?) CMake variables

Environment Details (include every applicable attribute)

• Operating System+version: CentOS 8
• Compiler+version: LLVM 10.1
• Conan version: 1.33.0
• Python version: 3.8.6

Steps to reproduce (Include if Applicable)

I have created this example repo: https://github.com/daravi/test-conan-profile

When using build/host profiles (at least some) CMake variables seem to not be generated. Specifically in the above example I try to display conan_<package_name>_root variable of a build_requirement. In the successful test, I just run conan install and then cmake and see the variable correctly printed out. In the fail case I run conan install with build and/or host profiles specified and run cmake again and see that the cmake variable has not been defined.

Logs (Executed commands with output) (Include/Attach if Applicable)

See: https://github.com/daravi/test-conan-profile

[jgsogo]

All the generators operate on all the information that they have available (propagation logic is controlled by the graph). Some generators will use only information from the host context and some others use information from the build context too.

Generators like cmake, cmake_find_package,… that are used to generate files with information from the dependencies you are going to use to link with your project/library, will generate only those files for packages in the host context. For example, say you are using protobuf library and you want to use protoc (provided by package protobuf) compile in Release while you want to build your project in Debug. Here you need:

class YourRecipe(ConanFile):

    def requirements(self):
        self.requires('protobuf/3.6.1')

    def build_requirements(self):
        self.build_requires('protobuf/3.6.1')

Given two profiles with Release in the build profile and Debug in the host profile, Conan needs to retrieve the same package twice, one for each configuration, and you will use in you CMakeLists.txt to find includes/libraries you want to link your project with:

find_package(protobuf)

You expect CMake to find the Debug package, which is the one that offers the configuration you are building. This is just an example, but you can realize that we cannot propagate the information from build AND host, we can only generate only FindProtobuf.cmake file and it will match the configuration from the host profile, which is the one you are linking with.

---

That was an example, I hope it explains a bit the problematic we are trying to fix here. Now let’s think about you scenario, you have a build-requires that provides some xxx.cmake files you want to use in your project. These CMake files can be a toolchain (and the package might be android_ndk) or just plain CMake files with utilities, functions and/or macros you need.

Disclaimer - We don’t have a canonical answer for it, we are designing a new conf paradigm to pass information to the new toolchain classes and generators. It will take into account this issue and should provide the solution that will be aligned with Conan 2.0.

Depending on the nature of your package you can use different approaches (I will use cmake-utils as the name of your package with CMake scripts):

• abuse generators built-in functionality. You can declare self.build_requires('cmake-utils', force_host_context=True) and Conan will force this build-requires to stay in the host context, Conan will generate the information you expect as with any other requirement. Of course, this will only work if the package doesn’t provide binaries you need to run in the build machine.

• propagate information using user_info entry:

  class CMakeUtils:
      def package_info(self):
         self.user_info.cmake_scripts_path = ['a/path/inside/this/package']
  

  and then, in the consumers, get the information via user_info_build

  class YourConsumer:
     build_requires = 'cmake-utils'
  
     def build(self):
        path_to_cmake_files = self.user_info_build['cmake_utils'].cmake_scripts_path
        ... copy them to the local folder, pass them to CMake,...
        cmake = CMake(self)
        cmake.definitions['PATH_TO_MY_SCRIPTS']  = path_to_cmake_files
  

In the future, we should be able to provide a more integrated way.

[daravi]

@jgsogo Thank you! For anyone reading the thread it is also possible to use CMakeToolchain if you don’t want to use virtualrunenv.