If feasible please add protoc and WellKnownTypes.proto to windows zip
Closed this issue · 5 comments
Thank you very much for the windows precompiled .zip file!
As a follow-up to one of the comments in #188, this asset would be even more useful if it included protoc
and the .proto
files that correspond to the WellKnownTypes.
Oh, that's quite hard, but I will try, also I don't really want to distribute 'protoc'. But I look into :)
Thank you for considering it. I'm not sure what the right thing to do is (either way) but I'm sure that it would be really nice (like, minimizing how much one has to mess around with windows) if the only action required to be able to use QtProtobuf were to unzip a single file and append -DCMAKE_PREFIX_PATH=c:\path_to_unzip\lib\cmake
. The specific error I'm getting is this:
C:\Users\Glen Mabey\src\my_project\src\build>cmake ..
-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.18363.
CMake Error at C:/Users/Glen Mabey/src/qtprotobuf-master-with-deps_2021-05-17/build/QtProtobufProtobufConfig.cmake:8 (include):
include could not find load file:
C:/Users/Glen Mabey/src/qtprotobuf-master-with-deps_2021-05-17/build/QtProtobufProtobufTargets.cmake
Call Stack (most recent call first):
C:/Users/Glen Mabey/src/qtprotobuf-master-with-deps_2021-05-17/build/QtProtobufConfig.cmake:20 (include)
CMakeLists.txt:171 (find_package)
CMake Error at C:/Users/Glen Mabey/src/qtprotobuf-master-with-deps_2021-05-17/build/QtProtobufProtobufConfig.cmake:12 (include):
include could not find load file:
C:/Users/Glen Mabey/src/qtprotobuf-master-with-deps_2021-05-17/build/protobufquickpluginTargets.cmake
Call Stack (most recent call first):
C:/Users/Glen Mabey/src/qtprotobuf-master-with-deps_2021-05-17/build/QtProtobufConfig.cmake:20 (include)
CMakeLists.txt:171 (find_package)
CMake Error at C:/Program Files/CMake/share/cmake-3.19/Modules/CMakeFindDependencyMacro.cmake:47 (find_package):
By not providing "FindWrapProtobuf.cmake" in CMAKE_MODULE_PATH this project
has asked CMake to find a package configuration file provided by
"WrapProtobuf", but CMake did not find one.
Could not find a package configuration file provided by "WrapProtobuf" with
any of the following names:
WrapProtobufConfig.cmake
wrapprotobuf-config.cmake
Add the installation prefix of "WrapProtobuf" to CMAKE_PREFIX_PATH or set
"WrapProtobuf_DIR" to a directory containing one of the above files. If
"WrapProtobuf" provides a separate development package or SDK, be sure it
has been installed.
Call Stack (most recent call first):
C:/Users/Glen Mabey/src/qtprotobuf-master-with-deps_2021-05-17/build/QtProtobufProtobufWellKnownTypesConfig.cmake:5 (find_dependency)
C:/Users/Glen Mabey/src/qtprotobuf-master-with-deps_2021-05-17/build/QtProtobufConfig.cmake:20 (include)
CMakeLists.txt:171 (find_package)
-- Configuring incomplete, errors occurred!
See also "C:/Users/Glen Mabey/src/my_project/src/build/CMakeFiles/CMakeOutput.log".
which doesn't look like it's even using the .zip file yet -- instead some remnants of my build-qtprotobuf-from-scratch effort are cropping up. If I was better at cmake+windows issues, I would have a better chance of making sense of this.
Anyway, that's my 2 cents ...
I was able to resolve some of my issues, but thought that I would contribute some of experiences.
I tried again to use the precompiled .zip of .lib files, and now I'm getting this error:
Qt5Protobuf.lib(qtprotobuf.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in mocs_compilation.cpp.obj
Qt5Protobuf.lib(qtprotobuf.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in mocs_compilation.cpp.obj
I assume this means that I need to compile QtProtobuf myself, right?
Also, I retract my request to include protoc
and .proto
files in the .zip ... closing.
Sorry, I'm not so good in Win32 ABI so I need time to make all this mess work correctly. Perhaps I miss some compiler/linker flags.
Yeah I'm no good with the Win32 stuff either ...
I think it's just worth helping users realize somehow that the .zip file might not work as smoothly as we all wished -- at least not for now.