Dependencies to protobuf sources

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Dependencies to protobuf sources

Stephan Menzel
Hello all,

I am a long term user of CMake, protobuf and grpc on Windows (MSVC15) and Linux.
Roughly in the beginning of this year I started to notice that dependencies of targets using generated sources to their appropriate protobuf files didn't work anymore. Basically, when I change a grpc source, the build system notices the change, re-runs the protoc and grpc compiler and builds. As it should. When I change a pure protobuf source however, nothing gets rebuilt. Which resulted in some nasty bugs lately.

I thought it might be a temporary bug and waited for several updates to protobuf, grpc, visual studio, cmake and everything else but so far it hasn't changed and now I finally decided I wanted to solve this as it slowly turns from a mild nuisance to a perilous situation in our team.

While doing so, I took a look at the 'new' way protobuf wants to be used. as opposed to what they call 'legacy' aka PROTOBUF_GENERATE_CPP and friends.

Nowadays they have this:

find_package(protobuf CONFIG REQUIRED)

add_library(my_protobuf_lib STATIC 
   SomeOfMySources.cpp
   Protosource.proto      // they expect the protos to be included right here
)

and then, judging from the source it should be enough to do this:

protobuf_generate(TARGET my_protobuf_lib)

Which looks nice and clean and I switched to this, hoping it may also solve the dependency bug. And it works in general, but the dependency still doesn't.
So I tried to add the dependency by force like this:

add_custom_target(my_protobuf_lib_protos DEPENDS Protosource.proto)
add_dependencies(my_protobuf_lib my_protobuf_lib_protos)

Still nothing. Right now I'm quite out of ideas of what else I could try so I thought I might ask here. The way I understand it those dependencies are supposed to work. And they have for many years until at some point in January 2018.
Unfortunately I cannot trace down the exact thing or date that broke it because it took me a while to notice. Since then, pretty much everything involved in the system has changed and upgraded multiple times. Protobuf is built externally and installed using its INSTALL target, then pulled into this project. Not built in tree. GRPC the same. The problem occurs everywhere. Windows, Linux, all distributions I build for. Ninja and make. I have tried all ways of building the protos available to me. 'Legacy', this new way, roll-your-own, using old cmake files from a time before the bug... nothing brought me anywhere. 
Right now all I know is there is what feels like a thousand ways to generate and build with protobuf but none of them have the dependencies in order. It might be worth noticing that Qt's auto-uic feature broke as well. Perhaps there is a connection. Manually generating the UICs still works and detects changes in the ui files but they are not recognized if I use auto-uic. This broke only recently though. Summer-ish.

Anybody has any ideas where I could look?

Thanks...
Stephan





--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Dependencies to protobuf sources

Stephan Menzel
On Sat, Oct 6, 2018 at 10:58 AM Stephan Menzel <[hidden email]> wrote:

protobuf_generate(TARGET my_protobuf_lib)


Well, it seems like this was the culprit all along. There is a bug in protobuf's usage of the add_custom_command. Appears this is known and fixed by:

but apparently not in their latest release tag version 3.6.1. Seems like it's been there for ages, which makes me wonder how this could have gone unnoticed for so long.

Anyway, fixing this locally in my installed cmake scripts fixes the problem. Above command workes nicely now. So it didn't have anything to do with auto-uic being broken. Onto the next one!

Cheers,
Stephan



--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake