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 Unsolved Qt Creator and other tools
5 Posts 2 Posters 207 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 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 Offline
      cristian-adamC Offline
      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 Offline
            cristian-adamC Offline
            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

            • Login

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