Using find_package(Protobuf) with 3.0.0

[Osse]

Hi,

I asked this on Google Groups and was advised to ask here and grab the attention of @podsvirov and @yeswalrus .

As of 3.0.0 the CMake module requires us to set protobuf_MODULE_COMPATIBLE in order to get the benefits of the module code such as protobuf_generate_cpp(). The example seems to refer to this as "legacy compatibility mode" but the commit message says it is "improved". I must admit I am a CMake newbie to begin with, but in any case I don't quite understand the intention: Am I supposed to set this variable? Am I supposed to not set it unless I have to?

Thanks,
Øsse

[podsvirov]

Hello @Osse,
you can use protobuf_MODULE_COMPATIBLE variable, and can not use.
Please look at the examples/CMakeLists.txt file to see both versions use.

[MSK61]

I think I got a conception of what all this is about. The config mode was the original mode with CMake and remained so for some time. That was how all third-party packages, protobuf included, advertised their targets and variables and allowed for their discoverability. Then later on came the module mode as the modern way to discover packages and get information about them, rendering the config mode somewhat obsolete(albeit still supported).

protobuf originally introduced the function protobuf_generate in the config mode. The function remained also available in the module mode when it got introduced to protobuf. The module mode however introduced 2 other new functions: protobuf_generate_cpp and protobuf_generate_python, which are convenience wrappers around the original protobuf_generate for some common use cases, as protobuf_generate was so versatile and could satisfy many use cases(albeit with complex parameters). Looks like these 2 new functions were intended exclusively for the module mode, but not the config mode; I don't know exactly really. The point is that these 2 functions are readily available for use in the module mode without any special arrangements. Those 2 functions are normally unavailable in the config mode(when protobuf_MODULE_COMPATIBLE is left to its default value of FALSE), but they can be requested explicitly by setting protobuf_MODULE_COMPATIBLE to TRUE. This explains a bit its naming denotation; it requests the config mode to be compatible with the module mode by making available the new functions the latter provides. It also explains the comments in the examples when this flag is set to TRUE, which means that we're using the legacy config mode with the new functions back-ported to it(upon our explicit request).

[Ryanf55]

Then later on came the module mode as the modern way to discover packages and get information about them, rendering the config mode somewhat obsolete(albeit still supported).

I don't agree, CONFIG is more desirable according to the CMake developers.
https://gitlab.kitware.com/cmake/cmake/-/issues/16805
https://github.com/CppCon/CppCon2019/blob/master/Presentations/deep_cmake_for_library_authors/deep_cmake_for_library_authors__craig_scott__cppcon_2019.pdf
See slide 105 and onward, providing Craig's recommendations which show using CONFIG mode with an export set.

To me, it would be most desirable to be able to find protobuf like so:
find_package(Protobuf REQUIRED COMPONENTS protoc)

Otherwise, right now, my call to find_package(Protobuf REQUIRED) is happy, but then I get a target that doesn't exist in the case that my Ubuntu installation only has libprotobuf-dev.

CMake Error at src/CMakeLists.txt:133 (add_custom_command):
  Error evaluating generator expression:

    $<TARGET_FILE:protobuf::protoc>

  No target "protobuf::protoc"

So, currently, I have to check all the cmake variables of the libraries are found after find_package anyways.

Why does Protobuf not distribute a CONFIG script with the COMPONENT support? Ceres does.