[cmake] Remove need for CMAKE_FIND_PACKAGE_PREFER_CONFIG

[DownerCase]

Description

CMAKE_FIND_PACKAGE_PREFER_CONFIG was recommended to have CMake (on Windows) find the vendored version of protobuf before falling back to the system findProtobuf.cmake module.

However, you can just manually implement this and try and find protobuf first through CONFIG then fallback to a required MODULE if not found.

This is one less thing to get wrong, I myself have forgotten this sharp corner, more than once, and wondered why everything fell over.

Tested on Windows with a local install of the installer and it works great 😄

Related issues

• Fixes unintuitive and atypical usage causing issues.
• Adds some missing newlines at the end of files (not a deliberate change, git was just upset they were missing and fixed them)

Cherry-pick to

[KerstinKeller]

The issue wasn't so much that we did want to find the vendored version. The issue was rather that FindProtobuf.cmake is buggy with regard to finding static Protobuf builds on Windows (and we never actually bothered to make a PR for that with CMake).

I neved like to have CMAKE_FIND_PACKAGE_PREFER_CONFIG in the samples, but the workaround you proposed is no less hacky 😄
I would propose to remove both the workaround and setting the cmake variable, and then note in the documentation (or elsewhere), that on Windows builds with the installer, the user should pass the variable on the command line from outside.

(For that matter neither am I a fan to provide an installer with an SDK, but totally different matter 😏 )

[DownerCase]

The issue wasn't so much that we did want to find the vendored version. The issue was rather that FindProtobuf.cmake is buggy with regard to finding static Protobuf builds on Windows (and we never actually bothered to make a PR for that with CMake).

I neved like to have CMAKE_FIND_PACKAGE_PREFER_CONFIG in the samples, but the workaround you proposed is no less hacky 😄 I would propose to remove both the workaround and setting the cmake variable, and then note in the documentation (or elsewhere), that on Windows builds with the installer, the user should pass the variable on the command line from outside.

(For that matter neither am I a fan to provide an installer with an SDK, but totally different matter 😏 )

I'd say the advantage of my change is that it maintains existing promoted behaviour but you can't do it wrong.

The prefer config setting is seldom used elsewhere and could (not saying it ever has) interfere with resolving other packages if set globally by the user.

Another option could be to configure the search paths of find_package to explicitly look for the vendored protobuf library on Windows first, though it looks like that was previously tried through CMAKE_MODULE_PATH. Something along the lines of find_package(protobuf NO_DEFAULT_PATH ${PACKAGE_PREFIX_DIR}/cmake/")

If you still want to stick with CMAKE_FIND_PACKAGE_PREFER_CONFIG being done by the user, I'll at least capture the find_package failure and issue an error saying to try it.