This is the only way I know to comment on blog posts.
I have been a big supporter of Protocol Buffers with my co-workers... even though I have not actively used it for about a year and a half.
The only issues we have faced were in migrating from 2 -> 3. If I recall, going from 2->3 meant we lost knowing if a parameter was used in a specific message.
A really nice feature is the ability to read/write the message in ASCII, then flip some switches and back to binary. This feature made debugging easier
Hi @ShamanTcler ! Thank you for commenting!
Thanks for the comments @ShamanTcler It was great job from @uilianries !
Just to make sure, is there something that is necessary to improve in the conan packages of Protobuf? If not, I will leave this issue open for some days, in case someone want to comment too, and then close it. Thanks!
Well being the "not the sharpest tool in the shed" I actually tried to build the project. I have chatted with @uilianries about the issue but here goes
My environment was MSVS 2015 and
conan install ..
cmake .. -DCMAKE_BUILD_TYPE=Release -G "Visual Studio 14 2015 Win64" -T v140
cmake --build . --config Release/Debug -T v140
cmake .. -DCMAKE_BUILD_TYPE=Release -G Ninja
bin/sensor
Was an epic fail ... MSBuild issues.
So I dropped back to my Unix roots and ditched MSBuild
conan install ..
cmake .. -DCMAKE_BUILD_TYPE=Release -G Ninja
ninja
bin/sensor
Worked like a champ. Though my ninja comes from kitware .... their Ninja supports FORTRAN too.
What is missing from the article is proof that the system works.
My code writes out the sensor.data file just fine, no struggling to the python code to read it.
But from previous exposure to PBs the file looks good.... for as well as I read binary.
Maybe the examples need a build script for windows, linux and mac?
And ci to make sure they work?
Maybe the examples need a build script for windows, linux and mac?
Yes, I totally agree. I should have used Windows + Visual Studio. As I'm a linux user, I just used my default environment.
And ci to make sure they work?
originally I used the project conan-protobuf-example to store the example, it has all CI stuff there. However, talking with Conan team we decided to create a repository to store all our examples. We can add CI support again, but it will more difficult since we have multiple project at same repo. BTW I prefer CI service instead of asciinema, since people can read the logs.
@memsharded Do you think we should update the post to use Visual Studio there?
But I did try in Windows with VS 2017 and worked nicely!
cmake .. -G "Visual Studio 15 2017 Win64"
cmake --build . --config Release
bin/sensor
>OK!
I think the difference could came from:
cmake .. -DCMAKE_BUILD_TYPE=Release -G "Visual Studio 14 2015 Win64" -T v140
cmake --build . --config Release/Debug -T v140
cmake .. -DCMAKE_BUILD_TYPE=Release -G Ninja
bin/sensor
It could be the difference in the toolset (Is it required? It is not the default in VS2015?)
Aslo, I don't get the second cmake project generator with -G Ninja. Did the first one failed? I think the second cmake .. -DCMAKE_BUILD_TYPE=Release -G Ninja is redundant?
If you could please clarify the exact steps to reproduce the issue, lets have a look!
Yes, I agree, setting up CI in the examples repo would be a good thing too, lets do it.
Using the example exactly with my MSVS 2015, Win 10, I was having MSBuild issues.
"D:\Users\210008258\github\conan-examples\libraries\protobuf\serialization\build\ALL_BUILD.vcxproj" (default target) (1
) ->
"D:\Users\210008258\github\conan-examples\libraries\protobuf\serialization\build\ZERO_CHECK.vcxproj" (default target) (
2) ->
(PlatformPrepareForBuild target) ->
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Platform.targets(55,5): error MSB8020: The build
tools for Visual Studio 2010 (Platform Toolset = 'v100') cannot be found. To build using the v100 build tools, please
install Visual Studio 2010 build tools. Alternatively, you may upgrade to the current Visual Studio tools by selecting
the Project menu or right-click the solution, and then selecting "Retarget solution". [D:\Users\210008258\github\conan
-examples\libraries\protobuf\serialization\build\ZERO_CHECK.vcxproj]
So after some searching I saw the flag -T v140 ( https://stackoverflow.com/questions/33380128/visual-studio-2015-command-line-retarget-solution/33386141 ) and decided to try that. None of it worked so I abandoned MSBuild and went back to Ninja. The line "cmake .. -DCMAKE_BUILD_TYPE=Release -G Ninja" was actually commented out but I copy paste it by mistake.
I know this stuff might seem to be pain in the a**, but the blog post are kinda like advertising... if a user gets good results in 5-10 min they stick around. If they have to debug THEIR system for an hour they are gone.
Incidentally I rewrote the build process a bit using cmake.conan. Our folks seem to prefer to see everything in one cmake file and an "out of source build" hence the rewrite. Oh, and this CMakeLists.txt does work in QtCreator.... just say'n. So you are happily mixing Qt and PB's ...
(Yup another "you say Tomato, I say Tomato")
Again let me say how much I appreciate the article.
I know this stuff might seem to be pain in the a**, but the blog post are kinda like advertising... if a user gets good results in 5-10 min they stick around. If they have to debug THEIR system for an hour they are gone.
I totally agree with you! It's really frustrating when you try to follow an example and it does not work at first. It sounds like, the author made extra steps that are not listed there.
For the next posts I'll use Visual Studio by default. Also, including the CI support will help people to check all steps required to build the full log.
Lets not over react here... you have said you are primarily a Unix guy ... go with it.
If you write and article and want some one to pre-release check it on windows I will be happy to oblige.
Take the lessons learned and then add a section "For the Windows folks:"
or even "For the Dockers folks:" , "For the Jenkins folks:"
and this could be a way to show practices that work (notice I did not say best practices)
Most helpful comment
Using the example exactly with my MSVS 2015, Win 10, I was having MSBuild issues.
"D:\Users\210008258\github\conan-examples\libraries\protobuf\serialization\build\ALL_BUILD.vcxproj" (default target) (1 ) -> "D:\Users\210008258\github\conan-examples\libraries\protobuf\serialization\build\ZERO_CHECK.vcxproj" (default target) ( 2) -> (PlatformPrepareForBuild target) -> C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Platform.targets(55,5): error MSB8020: The build tools for Visual Studio 2010 (Platform Toolset = 'v100') cannot be found. To build using the v100 build tools, please install Visual Studio 2010 build tools. Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution". [D:\Users\210008258\github\conan -examples\libraries\protobuf\serialization\build\ZERO_CHECK.vcxproj]So after some searching I saw the flag -T v140 ( https://stackoverflow.com/questions/33380128/visual-studio-2015-command-line-retarget-solution/33386141 ) and decided to try that. None of it worked so I abandoned MSBuild and went back to Ninja. The line "cmake .. -DCMAKE_BUILD_TYPE=Release -G Ninja" was actually commented out but I copy paste it by mistake.
I know this stuff might seem to be pain in the a**, but the blog post are kinda like advertising... if a user gets good results in 5-10 min they stick around. If they have to debug THEIR system for an hour they are gone.
Incidentally I rewrote the build process a bit using cmake.conan. Our folks seem to prefer to see everything in one cmake file and an "out of source build" hence the rewrite. Oh, and this CMakeLists.txt does work in QtCreator.... just say'n. So you are happily mixing Qt and PB's ...
CMakeLists.txt
(Yup another "you say Tomato, I say Tomato")
Again let me say how much I appreciate the article.