0

So I was running a project in Qt creator which was going relatively ok, where I needed to generate some protobuf files and link against them. So I used conan:

# conan
if(NOT EXISTS "${CMAKE_BINARY_DIR}/conan.cmake")
    message(STATUS "Downloading conan.cmake from https://github.com/conan-io/cmake-conan")
    file(DOWNLOAD "https://raw.githubusercontent.com/conan-io/cmake-conan/master/conan.cmake" "${CMAKE_BINARY_DIR}/conan.cmake")
endif()
include(${CMAKE_BINARY_DIR}/conan.cmake)

conan_cmake_run(CONANFILE conanfile.txt
    BASIC_SETUP
    CMAKE_TARGETS
    BUILD missing
    )

And then

find_package(protobuf       REQUIRED)
PROTOBUF_GENERATE_CPP(proto_h proto_c ${proto_files})

and then added those to "add_executable". Everything worked. Until I had to port this to Visual studio, where no files are being generated, and it does not seem like any custom build step related to Protobuf generation was added. I can't understand where is the issue. Also, CmakeGui was not able to find default protobuf related variables for some reason (Protobuf_LIBRARY_DEBUG-NOTFOUND etc.) but it was configured with no errors nonetheless (and PROTOBUF_GENERATE_CPP gave me file names to add the executable and it didn't swear that It can't find them = It should have found the protoc target to use it in its proto generation task).

So at this point I am out of Ideas and so frustrated because it seems that I have to resort to a manual protobuf download/install/search which might not even work=( Can someone give an idea why such things happen? Why QtCreator is perfectly capable of running CMake scripts while Visual studio files generated by the same CMake GUI the QtCreator has, cant?

UPDATE: Weirdly enough, after I opend CmakeLists in Visual studio and used x64-Configuration, everything worked. Although I had to manually type CMAKE_PREFIX_PATH Does it mean CmakeGui does not generate well?

drone
  • 43
  • 1
  • 9
  • '... and then added those to "add_executable"' - Please, show the code with `add_executable` call. Without that call (or if the call has wrong parameters) `PROTOBUF_GENERATE_CPP` would actually do nothing. – Tsyvarev Aug 18 '20 at 13:18
  • Those variables were linked to executable as the logging showed. If they weren't the project would not compile in QtCreator – drone Aug 18 '20 at 13:51
  • Look, you ask: "Why things goes wrong?". We could answer: "Probably, things goes wrong because something wrong in **your code**" (this is the most common reason of wrong behavior). Obviously, this is not the answer you want to hear, you want to know how to fix your code. But how would we point to the error in your code, if we don't see that code? Your explanations of your code are quite *vague*. The fact of working in QTCreator is not very useful: the code could be wrong but work in some situations. Or the code could simply contain a condition like `if(in_qt_creator)`. Please, show the code. – Tsyvarev Aug 18 '20 at 14:15
  • I am not a complete owner of the code so I don't feel like I can share it. Although I can say that all it boils down to is that I run conan, run the proto generation script, add the executable with all the source files (including those promised for generation by PROTOBUF_GENERATE_CPP) and then link all the targets the conan found to that executable. Cmake runs ok in creator and in VS, but after its configuration when the compilation starts, VS does not see the headers, because they were not generated, while in QtCreator's case they were. And by VS I mean the project generated by CmakeGui. – drone Aug 19 '20 at 07:10
  • Also I don't realy think you need to see the code in sthis situation, because it looks like the issue lies somwhere in the environment configuration or in some magic ways of handling CmakeGui. So I was hoping this would ring a bell among some experiensed users who have probably faced something like this already. – drone Aug 19 '20 at 07:15
  • "I can say that all it boils down to ..." - Nice, so you could be able to prepare [mcve] with **your own** code, so it will demonstrate the problem and won't violate license of the original code. Looking into this minimal example and its output (at least, the **exact error message**) we probably could be able to diagnose the problem. "I was hoping this would ring a bell among some experiensed users who have probably faced something like this already." - Most encounters of "weird errors" have its own, unique, reasons. And these reasons are discovered by inspecting a code, messages, etc. – Tsyvarev Aug 19 '20 at 07:40
  • why not generating proto files in plain cmake by "hand" instead of using conan etc ? see https://github.com/google/or-tools/blob/a0a56698ba8fd07b7f84aee4fc45d891a8cd9828/cmake/cpp.cmake#L234-L280 – Mizux Aug 20 '20 at 08:06

0 Answers0