Freetype with CMake 3.17 and higher versions

[Momo Als]

Hi,

We build Freetype 2.6.2 libraries through our CMake-generated project, so
in our tree we simply add Freetype as a subdirectory (i.e.
add_subdirectory(Freetype-2.6.2)). Afaik, since CMake 3.17 the following
warnings have been generated when generating the projects:











*CMake Warning (dev) at C:/Program
Files/CMake/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:273
(message):  The package name passed to `find_package_handle_standard_args`
(PkgConfig)  does not match the name of the calling package (HarfBuzz).
This can lead  to problems in calling code that expects `find_package`
result variables  (e.g., `_FOUND`) to follow a certain pattern.Call Stack
(most recent call first):  C:/Program
Files/CMake/share/cmake-3.18/Modules/FindPkgConfig.cmake:59
(find_package_handle_standard_args)
external_libs/Freetype-2.6.2/builds/cmake/FindHarfBuzz.cmake:35 (include)
external_libs/Freetype-2.6.2/CMakeLists.txt:217 (find_package)This warning
is for project developers.  Use -Wno-dev to suppress it.*
We changed to 2.10.2 in hope of an updated CMake file that fixes this but
the same problem remains, and moreover BrotliDec issues the same warning.
Not being familiar with the warning/problem I dug a bit deeper into it and
my wild guess is that warning is generated because of an outdated Harfbuzz
module. Right now there are several ways to avoid the warnings:

1. We don't use FT with Harfbuzz or Brotli so we simply comment out the
find_package calls for both in CMakeLists.txt (row 217 and 241). According
to the notes in CMakeLists.txt these calls only succeed if the dependencies
are available and not forced dependencies, and both are unavailable to us.

2. We send in arguments when running our script
(CMAKE_DISABLE_FIND_PACKAGE_Harfbuzz=TRUE etc.) or add it as a entry if
using CMake GUI, probably the cleaner solution.

3. We surpress the warnings with -Wno-dev

4. Avoid adding FT to our CMake tree entirely and just add pre-built
libraries (preferably want to avoid this)

Is there any plan to fix this for a new release, or is there any simple way
to do it without having to do a lot of changes in the CMakeLists or CMake
modules? The notes mention that the developer team doesn't normally use
CMakeLists.txt so I'm not sure if the CMake files are regularly maintained.

/ M