Using "build-scripts" package via tool_requires() not working

[tbsuht]

As suggested here, I open a dedicated issue.

See the setup as described here.
foobar contains generic cmake files which we want to use in a lot of projects. The problem is that when using the package via tool_requires, the files can't be found. We are currently bypassing this by using requires and a dedicated find_package.

My understand is that the builddirs information is not used, as it is placed in the generated toolchain file and we're using the one-click-workflow of the CMake extension without manually doing a conan install before.

[memsharded]

Hi @tbsuht

Thanks for your question.

My understand is that the builddirs information is not used, as it is placed in the generated toolchain file and we're using the one-click-workflow of the CMake extension without manually doing a conan install before.

Indeed, the problem is that cmake-conan launches from CMake, and the way that Conan has to pass paths from tool_requires is a toolchain, but as cmake-conan starts from CMake, it is not possible to pass the conan_toolchain.cmake, it is too late.

I'd say that the scope of cmake-conan is limited to what CMake can reasonably do in a single pass. Conan allows more advanced uses cases, like reusing build scripts from dependencies, but at some point the conan install + cmake flow would be more recommended as more complete and powerful, sometimes it is not possible to just do absolutely everything from a single command cmake invocation, as there are limitations.

It might be possible to do some gymnastics like parsing the json and extracting the builddirs, then defining those in the module path, I'll talk with @jcar87 regarding this possibility.

[ericriff]

I just came across the same limitation.

I'm trying to use this integration on a project that relies on protobuf / protoc. I can access the protobuf library, but not the protoc binary.

I'm interested on any suggestions.

[drmacdon]

I had the same problem and ended up commenting out the find_program line in the protobuf-conan-protoc-target.cmake of the protobuf recipe.

I don't understand the circumstances under which it would be needed as line 14 was specifically looking for the recipes currently built protoc (the one I wanted) and unlike the find_program on line 5 it will find any protoc in the PATH.

When the (uncommented) protobuf recipe is invoked with conan the search PATH is correct as conan can inject, however when it is invoked from the conan_provider.cmake, it finds the platform installed protoc if it exists because it's allowed to search the default search path.

I am using protobuf/3.21.12 and my homebrew system protoc is a different version so must use recipe version (although I would never want system installed even if it did match). I use conan for cross-compile profiles, but use conan_provider.cmake for local builds in CLion.

The find_program I removed feels redundant but there are a lot of permutations and its possible I'm overlooking something but it "works for me" so thought I'd annotate this ticket in the event it helps @ericriff.

[memsharded]

Hi all,

When conan ... is invoked, it has full control. It can take tool_requires, put those tool-requires bindirs in the PATH, and then execute all the build commands with that environment defined, plus a bunch of other configuration it can inject both via environment and via conan_toolchain.cmake, with contains a specific block with paths so all find_program and similar calls, can find things inside Conan packages.

When cmake ... is the driver, this is no longer possible. The conan_toolchain.cmake cannot be used anymore, because cmake is already running and conan is called just the first time a find_package() is found, but that is too late to be able to use the conan_toolchain.cmake.

I will try to discuss with @jcar87 about possible approaches for this tool_requires.

[drmacdon]

Thanks @memsharded, it definitely would be a nicer approach and be more seamless for all recipes than the current protobuf recipe approach. (Although @ericriff should be able to get protoc to work today with the above modification.)