should I expect a package to include its link dependencies

[willie]

For example, opentelemetry-cpp package has a dependency on protobuf, but it fails at link time because it cannot find libprotobuf. If I add protobuf¹

find_package(Protobuf CONFIG REQUIRED)
target_link_libraries(${CMAKE_PROJECT_NAME} PRIVATE protobuf::libprotobuf)

to my project's CMakeLists.txt file, then it links correctly. Should I expect the package to already know this dependency? Does this vary from package to package? If I were to try and fix this for the packages I encounter this with, what's the correct way to start?

Footnotes

1. protobuf throws a bunch of errors if you use lowercase find_package(protobuf CONFIG REQUIRED), which is another issue, like how do you fix this without breaking existing usage? ↩

[Osyotr]

It's upstream responsibility to add required find_dependency calls into their exported configs. Some packages do it properly, some don't. Vcpkg does try to fix such problems (though I don't think it's explicitly mentioned anywhere). opentelementry-cpp already has one patch that adds required find_dependency call, though not for protobuf.
The fix varies from port to port, check out github search for find_dependency to gather some inspiration: link.

protobuf throws a bunch of errors if you use lowercase find_package(protobuf CONFIG REQUIRED), which is another issue, like how do you fix this without breaking existing usage?

What errors? CMake searches for a file called <lowercasePackageName>-config.cmake or <PackageName>Config.cmake, thus find_package(protobuf CONFIG REQUIRED) is the correct usage, because installed config file name is protobuf-config.cmake. see #36934 (reply in thread)

[Osyotr]

no errors

Unless you try to build it on linux

[willie]

Actually, yes, exact same behavior on Linux.

#17 1.559 -- Found Protobuf: /saturnv/build/vcpkg_installed/arm64-linux/tools/protobuf/protoc (found version "3.21.12.0") 
#17 1.559 CMake Warning (dev) at /usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
#17 1.559   The package name passed to `find_package_handle_standard_args` (Protobuf)
#17 1.559   does not match the name of the calling package (protobuf).  This can lead
#17 1.559   to problems in calling code that expects `find_package` result variables
#17 1.559   (e.g., `_FOUND`) to follow a certain pattern.
#17 1.559 Call Stack (most recent call first):
#17 1.559   build/vcpkg_installed/arm64-linux/share/protobuf/protobuf-module.cmake:162 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
#17 1.559   build/vcpkg_installed/arm64-linux/share/protobuf/protobuf-config.cmake:168 (include)
#17 1.559   build/vcpkg_installed/arm64-linux/share/protobuf/vcpkg-cmake-wrapper.cmake:16 (_find_package)
#17 1.559   vcpkg/scripts/buildsystems/vcpkg.cmake:813 (include)
#17 1.559   CMakeLists.txt:357 (find_package)
#17 1.559 This warning is for project developers.  Use -Wno-dev to suppress it.

[Osyotr]

Does find_package(Protobuf CONFIG) works for you on Linux?

[dg0yt]

From what I observe here, my conclusion is that the official usage must be

find_package(Protobuf [CONFIG])

which is a supported package name for both the config and the find module.
However, because upstream chose the case-insensitive spelling for the cmake config filename, the vcpkg tool usage heuristics is unable to suggest the desired spelling.

[willie]

Does find_package(Protobuf CONFIG) works for you on Linux?

Yes.

[mail96350]

[willie]

Please delete this.

[mail96350]

You mean my comment ? Why?

[willie]

Because it's irrelevant to the topic of this discussion.

[mail96350]

Ok I will delete it but tell me how to create a new topic to post this request

[StarGate-One]

@mail96350

Ok I will delete it but tell me how to create a new topic to post this request

See #30604 How to report a build failure [explanation video]

Start here

[willie]

It's upstream responsibility to add required find_dependency calls into their exported configs. Some packages do it properly, some don't. Vcpkg does try to fix such problems (though I don't think it's explicitly mentioned anywhere). opentelementry-cpp already has one patch that adds required find_dependency call, though not for protobuf. The fix varies from port to port, check out github search for find_dependency to gather some inspiration: link.

Thanks for this answer, BTW. It was the real answer to the question, but given the direction we took about Protobuf, I marked that one. I will try to figure out the find_dependency usage. I appreciate the guidance.

[dg0yt]

Please mark the real answer. My point was that port protobuf needs an explicit usage file, to end confusion.

[willie]

Also related, people noting the same issue on the upstream repo (just recently, though): open-telemetry/opentelemetry-cpp#2528