[wxwidgets] Fix find_package error

[LilyWangL]

Describe the pull request

• What does your PR fix? Fixes wxwidgets installed but not detected by FindwxWidgets.cmake #4756
  Add vcpkg-cmake-wrapper.cmake to use FindwxWidgets.cmake to find wxwidgets.
• Which triplets are supported/not supported? Have you updated the CI baseline?
  No
• Does your PR follow the maintainer guide?
  Yes

[cenit]

Why should we copy a default cmake module inside vcpkg?

[LilyWangL]

Why should we copy a default cmake module inside vcpkg?

If doesn't set this to make wxwidgets use default cmake module inside vcpkg, it will use the cmake module inside Visual Studio and it can not find wxwidgets.

[Neumann-A]

If doesn't set this to make wxwidgets use default cmake module inside vcpkg, it will use the cmake module inside Visual Studio and it can not find wxwidgets.

That is basically true for all modules using the wrong cmake version.

vcpkg should just get over it and add a cmake modules folder which is basically a copy of cmake findModules which get improved over time and maybe commited into cmake itself (That is basically what VTK does).... but no we have vcpkg-cmake-wrapper.cmake and have to live with that.

[LilyWangL]

Thanks for your review, it is my fault. I test again FindwxWidgets.cmake provided by cmake of Visual Studio and VCPKG on locally, and I get the same error:

1> [CMake]   Could NOT find wxWidgets (missing: wxWidgets_LIBRARIES
1> [CMake]   wxWidgets_INCLUDE_DIRS core base)

I find port gppanel use FindwxWidgets.cmake, it add patch to modify FindwxWidgets.cmake provided by cmake. Use this FindwxWidgets.cmake can find wxwidgets successfully.

1> [CMake] -- Found wxWidgets: E:/0817/vcpkg/installed/x86-windows/lib/wxmsw31u_core.lib;E:/0817/vcpkg/installed/x86-windows/lib/wxbase31u.lib;winmm;comctl32;uuid;oleacc;uxtheme;rpcrt4;shlwapi;version;wsock32 (found version "3.1.4") found components: core base missing components: png tiff jpeg zlib regex expat
1> [CMake] wxWidgets_LIBRARIES: E:/0817/vcpkg/installed/x86-windows/lib/wxmsw31u_core.lib;E:/0817/vcpkg/installed/x86-windows/lib/wxbase31u.lib;winmm;comctl32;uuid;oleacc;uxtheme;rpcrt4;shlwapi;version;wsock32

I will add new vcpkg-cmake-wrapper.cmake to use find_path and find_library to find wxwidgets. @BillyONeal what do you think about it?

[BillyONeal]

If we're patching the default module somehow that's OK, but we should probably avoid deploying a module identical to that which ships with cmake (and request that users use a more recent version if we need that).

[cbezault]

I don't know. I kind of think @Neumann-A's suggestion isn't that bad of an idea.

However, under the current status quo this seems like not a terrible thing to do.

[ras0219]

The reason we don't want to commit a copy of CMake's modules is because we don't want to downgrade the user's modules moving into the future. If they use today's vcpkg tool against CMake 3.20, we don't want to force them back down to CMake 3.17/18.

[Neumann-A]

If they use today's vcpkg tool against CMake 3.20, we don't want to force them back down to CMake 3.17/18.

If a module is updated it is very probably that a vcpkg-cmake-wrapper.cmake also needs updating or removal.
Most changes to FindModules in cmake is the addition of targets. vcpkg does not need to ship a direct copy of cmake's modules. It just can be a module defining the same visible variables as CMake but in addition has internal knowledge of the directory structure vcpkg uses. Writing a good and correctly working vcpkg-cmake-wrapper.cmake already requires internal knowledge of the corresponding cmake module so dropping this indirection would make corrections a lot easier.

[ras0219]

I spent some time looking at the built-in wxwidgets module and it seems too complex to realistically shim; in this case, I agree that a replacement is warranted and I've opened #13361 with that approach.

[PhoebeHui]

Duplicated to #13361.