Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Qt Creator and other tools
  4. QtCreator cannot find CMake conan dependency files when using Conan 2.24

QtCreator cannot find CMake conan dependency files when using Conan 2.24

Scheduled Pinned Locked Moved Solved Qt Creator and other tools
10 Posts 2 Posters 461 Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C Offline
    C Offline
    cancech
    wrote last edited by
    #1

    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-adamC 1 Reply Last reply
    0
    • C Offline
      C Offline
      cancech
      wrote last edited by
      #9

      Newer versions of Conan2 introduce a CMakeConfigDeps generator, which performs the same CMakeDeps configuration that I was trying to do manually. Switching to that bypasses the error in Qt and allows for CMake generation to proceed as desired. I ran into some CMake issues which I needed to resolve, which for some reason didn't seem to be present otherwise, but once those were resolved everything seems to be working fine. The summary of what I needed to change was:

      In the cmake-common containing the shared CMake files:

      • remove the package_type
      • remove the generators
      • remove the package_info configuration for builddirs
      • add a cmake_build_modules property, listing all of the cmake files that are to be shared

      The end result looks like:

      class CmakeCommonRecipe(ConanFile):
          name = "cmake-common"
          version = "1.2.3"
      
          def package(self):
              copy(self, "*.cmake", self.source_folder, self.package_folder, keep_path=True)
              
          def package_info(self):
              self.cpp_info.set_property("cmake_build_modules", ["file1.cmake", "file2.cmake"])
      

      On the consumer side, the conanfile.py needs to be updated to add CMakeConfigDeps to the generators, resulting in:

      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}
          generators = "CMakeConfigDeps"
      
          tool_requires = "cmake-common/0.0.1"
      

      And the CMakeLists.txt changes the include for find_package, resulting in:

      cmake_minimum_required(VERSION 3.27.7)
      
      find_package(cmake-common CONFIG REQUIRED)
      
      # ... and so on
      
      cristian-adamC 1 Reply Last reply
      1
      • C 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-adamC Online
        cristian-adamC Online
        cristian-adam
        wrote last edited by
        #2

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

        1 Reply Last reply
        0
        • C Offline
          C Offline
          cancech
          wrote last edited by
          #3

          @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)

          1 Reply Last reply
          0
          • C Offline
            C Offline
            cancech
            wrote last edited by
            #4

            @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-adamC 1 Reply Last reply
            1
            • C 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-adamC Online
              cristian-adamC Online
              cristian-adam
              wrote last edited by
              #5

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

              1 Reply Last reply
              0
              • C Offline
                C Offline
                cancech
                wrote last edited by
                #6

                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-adamC 1 Reply Last reply
                1
                • C 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-adamC Online
                  cristian-adamC Online
                  cristian-adam
                  wrote last edited by
                  #7

                  @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.

                  1 Reply Last reply
                  0
                  • C Offline
                    C Offline
                    cancech
                    wrote last edited by cancech
                    #8

                    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.

                    1 Reply Last reply
                    0
                    • C Offline
                      C Offline
                      cancech
                      wrote last edited by
                      #9

                      Newer versions of Conan2 introduce a CMakeConfigDeps generator, which performs the same CMakeDeps configuration that I was trying to do manually. Switching to that bypasses the error in Qt and allows for CMake generation to proceed as desired. I ran into some CMake issues which I needed to resolve, which for some reason didn't seem to be present otherwise, but once those were resolved everything seems to be working fine. The summary of what I needed to change was:

                      In the cmake-common containing the shared CMake files:

                      • remove the package_type
                      • remove the generators
                      • remove the package_info configuration for builddirs
                      • add a cmake_build_modules property, listing all of the cmake files that are to be shared

                      The end result looks like:

                      class CmakeCommonRecipe(ConanFile):
                          name = "cmake-common"
                          version = "1.2.3"
                      
                          def package(self):
                              copy(self, "*.cmake", self.source_folder, self.package_folder, keep_path=True)
                              
                          def package_info(self):
                              self.cpp_info.set_property("cmake_build_modules", ["file1.cmake", "file2.cmake"])
                      

                      On the consumer side, the conanfile.py needs to be updated to add CMakeConfigDeps to the generators, resulting in:

                      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}
                          generators = "CMakeConfigDeps"
                      
                          tool_requires = "cmake-common/0.0.1"
                      

                      And the CMakeLists.txt changes the include for find_package, resulting in:

                      cmake_minimum_required(VERSION 3.27.7)
                      
                      find_package(cmake-common CONFIG REQUIRED)
                      
                      # ... and so on
                      
                      cristian-adamC 1 Reply Last reply
                      1
                      • C cancech has marked this topic as solved
                      • C cancech

                        Newer versions of Conan2 introduce a CMakeConfigDeps generator, which performs the same CMakeDeps configuration that I was trying to do manually. Switching to that bypasses the error in Qt and allows for CMake generation to proceed as desired. I ran into some CMake issues which I needed to resolve, which for some reason didn't seem to be present otherwise, but once those were resolved everything seems to be working fine. The summary of what I needed to change was:

                        In the cmake-common containing the shared CMake files:

                        • remove the package_type
                        • remove the generators
                        • remove the package_info configuration for builddirs
                        • add a cmake_build_modules property, listing all of the cmake files that are to be shared

                        The end result looks like:

                        class CmakeCommonRecipe(ConanFile):
                            name = "cmake-common"
                            version = "1.2.3"
                        
                            def package(self):
                                copy(self, "*.cmake", self.source_folder, self.package_folder, keep_path=True)
                                
                            def package_info(self):
                                self.cpp_info.set_property("cmake_build_modules", ["file1.cmake", "file2.cmake"])
                        

                        On the consumer side, the conanfile.py needs to be updated to add CMakeConfigDeps to the generators, resulting in:

                        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}
                            generators = "CMakeConfigDeps"
                        
                            tool_requires = "cmake-common/0.0.1"
                        

                        And the CMakeLists.txt changes the include for find_package, resulting in:

                        cmake_minimum_required(VERSION 3.27.7)
                        
                        find_package(cmake-common CONFIG REQUIRED)
                        
                        # ... and so on
                        
                        cristian-adamC Online
                        cristian-adamC Online
                        cristian-adam
                        wrote last edited by
                        #10

                        @cancech Thank you for the follow up!

                        1 Reply Last reply
                        0

                        • Login

                        • Login or register to search.
                        • First post
                          Last post
                        0
                        • Categories
                        • Recent
                        • Tags
                        • Popular
                        • Users
                        • Groups
                        • Search
                        • Get Qt Extensions
                        • Unsolved