QtCreator cannot find CMake conan dependency files when using Conan 2.24

cancech

I'm in the processes of trying to upgrade from Conan 1.66 to Conan 2.24 and while everything works perfectly fine when running a build on the command line with Conan 2.24 and opening the project in QtCreator (version 18.0.1) with Conan 1.66, the build fails when trying to open my project in QtCreator with Conan 2.24. The issue stems from a Conan dependency named cmake-common, which is a shared project containing various reusable CMake scripts (no C++ code or binary elements as such). My project recipe lists cmake-common as a dependency, and I can see in QtCreator that it is successfully installed and pulled in, however when the CMake configuration for my project itself runs, it fails because it cannot find the contents of cmake-common.

The recipe/package for cmake-common is setup largely in the same way as what can be seen here:

class CmakeCommonRecipe(ConanFile):
    name = "cmake-common"
    version = "1.2.3"
    package_type = "build-scripts"
    generators = ["CMakeToolchain"]

    def package(self):
        copy(self, "*.cmake", self.source_folder, self.package_folder, keep_path=True)
        
    def package_info(self):
        self.cpp_info.builddirs = ["macros"]

The consumer (my project in this case) then lists cmake-common/1.2.3 as a tool_requires dependency in its recipe

class MyProjectRecipe(ConanFile):
    name = "my-project"
    version = "1.2.3"
    settings = "os", "compiler", "build_type", "arch"
    options = {"shared": [True], "fPIC": [True, False]}
    default_options = {"shared": True, "fPIC": True}

    tool_requires = "cmake-common/0.0.1"

and then accesses the cmake-common contents in its CMakeLists.txt

cmake_minimum_required(VERSION 3.27.7)

# cmake-common-macros.cmake is provided by cmake-common and contains a series of include(<file>) for
# all of the other files that cmake-common contains. Thus, this is purely an entry point into cmake-common
include(cmake-common-macros)

# ... and so on

As mentioned, this works perfectly fine if running on the command like with Conan 2.24 (or Conan 1.66 for that matter), and when running CMake in QtCreator with Conan 1.66, but fails in QtCreator when running with Conan 2.24:

[cmake] CMake Error at CMakeLists.txt:3 (include):
[cmake]   include could not find requested file:
[cmake] 
[cmake]     cmake-common-macros

Since the entry cmake-common-macros cannot be found, then of course none of the functions/macros my project tries to use that cmake-common provides work either. I don't know why this would be...

Any thoughts as to what could be going on? I don't think that there are any issues with either the Conan or CMake scripts/configurations as those work elsewhere and do work with Conan 1.66 in QtCreator. Is there something that needs to be done to tell QtCreator to include Conan dependencies into its "CMake Path" or something like that?

Note: I can successfully include the file if I provide the absolute path to it, however then it fails because it cannot find the nested file it tries to include as those are also included as a relative path.

cristian-adam

@cancech feel free to open a bug report and provide a small project that reproduces the issue. I will have a look there.

cancech

@cristian-adam Thanks, I'll try to open the bug report and a reproducing example later today.

For the time being we've been digging into this some more and while we're no closer to figuring out this issue, one question: Is there a difference in QtCreator in how it deals with tool_requires as compared to requires?

In our situation we have a dependency on FakeIt and we can see that a number of fakeit*.cmake files are created for it in the conan-dependency/*/generators directory by QtCreator but no such files are present for cmake-common (note, I'm also thinking that these cmake-common.cmake files were created by Conan 1 but are no longer created by Conan 2 for some reason)

cancech

@cristian-adam I've raised a bug report per your suggestion.

I added all of the relevant information into the report, but just as a follow-up here - while preparing the example reproducing the issue I found a potential hint as to what might be going on. Namely, it appears when then running with Conan 2 QtCreator appears to try and process the project CMakeLists.txt before performing the conan install, thus the include(cmake-common-macros) is attempted before the cmake-common dependency providing it is made available. Or at least that's what appears to be going on. The output from the example shows the include(cmake-common-macros) as soon as I run CMake and only later in the output can I see that the conan install takes place.

cristian-adam

@cancech Thank you for the bug report. I've updated the ticket with my thoughts.

cancech

I've been gradually chipping away at this problem, and one issue that has been cropping up is that QtCreator is forcing the CMakeDeps generator use when executing conan, which in turn prevents me from customizing the CMakeDeps generator in my conanfile.py. Basically if I try to customize the CMakeDeps like so:

        deps = CMakeDeps(self)
        deps.build_context_activated = ["cmake-common"]
        deps.build_context_build_modules = ["cmake-common"]
        deps.generate()

then conan errors out with the message ConanException: CMakeDeps is declared in the generators attribute, but was instantiated in the generate() method too. It should only be present in one of them.. As far as I can tell, this is caused by how QtCreator is triggering Conan, as I can find the following in one of the CMakeLists.txt that QtCreator generates

          foreach(type ${build_types})
            conan_install(
              -pr "C:/dev/my-project/build/Desktop_Qt_6_9_3_MinGW_64_bit-Debug/conan-dependencies/conan_host_profile"
              --build=missing
              -s build_type=${type}
              -g CMakeDeps)
          endforeach()

Is there any way to turn this behavior off? Basically, something that would allow me to tell QtCreator to stop forcing the use of CMakeDeps and allow me to control how is it created/customized?

cristian-adam

@cancech The code at https://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/share/3rdparty/cmake-helper/package-manager.cmake#n92

has such a check:

      # conanfile should have a generator specified, when both file and conan_install
      # specifcy the CMakeDeps generator, conan_install will issue an error
      file(READ "${conanfile_txt}" conanfile_text_content)
      unset(conan_generator)
      if (NOT "${conanfile_text_content}" MATCHES ".*CMakeDeps.*")
        set(conan_generator "-g CMakeDeps")
      endif()

But for some reason is not working in your case. I did try the bugreport that you provided, but didn't work for me.

If you can have a look or tweak the reproducer in the bug report ... it would speed up the fix.

cancech

Oh, I think I know why that is... I didn't include this to simplify the example I prepared, but the actual conanfile.py recipe builds upon/inherits a shared/common recipe from another conan package (basically I have a conan package with reusable base recipes that my project then merely tweaks). Therefore the conanfile.py in my workspace doesn't explicitly specify CMakeDeps but the "parent" recipe does.

I'll update the example accordingly so that you are able to reproduce the issue.

Update:
@cristian-adam I've updated the bug report with this information and attached and update sample which reproduces the problem.