conan icon indicating copy to clipboard operation
conan copied to clipboard

[question] Build Requirement Usage

Open radonish opened this issue 2 years ago • 1 comments

Hello,

I'm trying to use the build_requires feature and it's not behaving how I thought I understood it to work. Essentially this is the use case:

  • All packages are built with multiple profiles; for this example let's say we have an x86_64 profile and an arm profile
  • Package appX requires package buildHelperX for building

Thus, appX lists buildHelperX in its build_requires section. appX is built via CMake, so it has something like this in its CMakeLists.txt: set(BUILD_HELPERX_BIN_PATH ${CONAN_BIN_DIRS_BUILD_HELPERX}/build_helper)

CONAN_BIN_DIRS_BUILD_HELPERX is set within the generated conanbuildinfo.cmake file.

My problem is that when my build system goes to build (conan create) appX for the arm profile, it attempts to execute (within the CMakeLists.txt, using the variable in my example above) the build helper binary for the arm profile instead of that of the build machine (the x86_64 profile).

I tried to explicitly specify a build and host profile for conan create by using the --profile:build <build profile> --profile:host <host profile> but then I notice that the conanbuildinfo.cmake file does not have path variables for the build_requires build helper package. If my CMakeLists.txt does not have the path variables from conanbuildinfo.cmake I'm not sure how I'd know where to find them from within the local Conan cache.

What am I doing wrong?

Thank you!

radonish avatar Jul 23 '22 01:07 radonish

Hi @radonish - thanks for raising this question.

You're on the right track: when you are cross building a project that has dependencies, any executable that needs to be executed during that build, that also comes as a dependency, needs to be built to run on the machine doing the build (hence the "build" profile).

I would avise to use the new syntax (tool_requires) and the new CMake generators as oppose to the legacy, which are aware of the two profiles (build and host) and provide better control.

    def requirements(self):
        self.requires("zlib/1.2.12")

    def build_requirements(self):
        self.tool_requires("patchelf/0.13")
        
    def generate(self):
        cmake = CMakeDeps(self)
        cmake.build_context_activated = ["patchelf/0.13"]
        cmake.generate()

and then invoke conan install using both profiles and the CMakeToolchain generator. In this instance, Conan will correctly pull patchelf such that the executable can run on the current machine, but zlib for the architecture we are building for. In this case, the variables defined in the generated conan_toolchain.cmake will point to patchelf for the build machine - but you may need to include additional information in the recipe of patchelf itself to propagate the correct information.

jcar87 avatar Jul 25 '22 16:07 jcar87