QtCreator successful opens project with Conan 1.66 but not with Conan 2.24
-
My project uses
Conanfor dependency management andCMakefor build management/configuration; I can open said project inQtCreator (18.0.1)without any problems if I do so usingConan 1.66. I'm however in the process of switching toConan 2, and the same project (no change in either code, CMake scripts, or Conan recipe) does not want to open if I try to open it using the latestConan 2.24. There are no issues when trying to build the project from the command line usingConan(i.e.:conan installandconan creatework perfectly withConan 2.24when run in the project folder), which make me think that there are no issues with either theCMakescripts or theConanrecipe.To avoid defining various shared values in both
CMakeandConan, both are configured to load aproject.detailsfile located in the root of the project directory which contains project metadata that both require (such as project name and version).Conanis accessing it via theself.recipe_folderandCMakein theCMAKE_CURRENT_SOURCE_DIR. In a nutshell, this is ultimately the same thing as what the officialConandocumentation shows for theset_name()method, albeit with some additional steps.As mentioned, this all works perfectly fine in
QtCreatorif I useConan 1.66, or withConan 2.24if I perform a build viaConanon the command line (conan create .). However if I try to open this project inQtCreatorwithConan 2.24then I get the following error[cmake] ERROR: [cmake] FileNotFoundError: [Errno 2] No such file or directory: 'C:/myproject/build/Desktop_Qt_6_9_3_MinGW_64_bit-Debug/conan-dependencies\\project.details' [cmake] CMake Error at C:/myproject/build/Desktop_Qt_6_9_3_MinGW_64_bit-Debug/.qtc/package-manager/conan_provider.cmake:463 (message): [cmake] Conan install failed='1' [cmake] Call Stack (most recent call first): [cmake] CMakeLists.txt:19 (conan_install)From what I can tell, this is due to
QtCreatorwhen usingConan 2.24creating its ownrecipe_folderat<build_dir>/.qtc/package-managerand executingConanfrom that directory rather than from within the project root. While the project'sconanfile.pyis copied over to the.qtc/package-managerdirectory, my customproject.detailsis not, thus the error. If up update myConanrecipe to load theproject.detailsfrom the hard-coded absolute path the file is actually loaded in, it gets past this step.Is there a way to tell
QtCreatorto copy myproject.detailsalong with theconanfile.pywhen building its customrecipe_folder?The only other option I can think of would be to update the
conanfile.pyto load the file from the project root directory rather thanrecipe_folder, but I have not been able to find any reference to "project root" from within theConanrecipe. -
My project uses
Conanfor dependency management andCMakefor build management/configuration; I can open said project inQtCreator (18.0.1)without any problems if I do so usingConan 1.66. I'm however in the process of switching toConan 2, and the same project (no change in either code, CMake scripts, or Conan recipe) does not want to open if I try to open it using the latestConan 2.24. There are no issues when trying to build the project from the command line usingConan(i.e.:conan installandconan creatework perfectly withConan 2.24when run in the project folder), which make me think that there are no issues with either theCMakescripts or theConanrecipe.To avoid defining various shared values in both
CMakeandConan, both are configured to load aproject.detailsfile located in the root of the project directory which contains project metadata that both require (such as project name and version).Conanis accessing it via theself.recipe_folderandCMakein theCMAKE_CURRENT_SOURCE_DIR. In a nutshell, this is ultimately the same thing as what the officialConandocumentation shows for theset_name()method, albeit with some additional steps.As mentioned, this all works perfectly fine in
QtCreatorif I useConan 1.66, or withConan 2.24if I perform a build viaConanon the command line (conan create .). However if I try to open this project inQtCreatorwithConan 2.24then I get the following error[cmake] ERROR: [cmake] FileNotFoundError: [Errno 2] No such file or directory: 'C:/myproject/build/Desktop_Qt_6_9_3_MinGW_64_bit-Debug/conan-dependencies\\project.details' [cmake] CMake Error at C:/myproject/build/Desktop_Qt_6_9_3_MinGW_64_bit-Debug/.qtc/package-manager/conan_provider.cmake:463 (message): [cmake] Conan install failed='1' [cmake] Call Stack (most recent call first): [cmake] CMakeLists.txt:19 (conan_install)From what I can tell, this is due to
QtCreatorwhen usingConan 2.24creating its ownrecipe_folderat<build_dir>/.qtc/package-managerand executingConanfrom that directory rather than from within the project root. While the project'sconanfile.pyis copied over to the.qtc/package-managerdirectory, my customproject.detailsis not, thus the error. If up update myConanrecipe to load theproject.detailsfrom the hard-coded absolute path the file is actually loaded in, it gets past this step.Is there a way to tell
QtCreatorto copy myproject.detailsalong with theconanfile.pywhen building its customrecipe_folder?The only other option I can think of would be to update the
conanfile.pyto load the file from the project root directory rather thanrecipe_folder, but I have not been able to find any reference to "project root" from within theConanrecipe.Qt Creator CMakeProjectManager's package manager auto-setup is trying to setup the environment where CMake can find packages and successfully configure the project.
For conan a simple CMake probe project is set up which uses conan-cmake to do the
conan installparts.It doesn't sound as
project.detailsa standard Conan feature is.There is a customization point in the package-manager.cmake, at the top of the file:
if (EXISTS "${CMAKE_SOURCE_DIR}/QtCreatorPackageManager.cmake") include("${CMAKE_SOURCE_DIR}/QtCreatorPackageManager.cmake") endif()You can create a
QtCreatorPackageManager.cmakefile where you have the statement:file(COPY "${CMAKE_CURRENT_LIST_DIR}/project.details" DESTINATION "${CMAKE_BINARY_DIR}/conan-dependencies/") -
C cancech has marked this topic as solved
-
@cristian-adam Thank you so much! This solves my issue perfectly!