[CMake] FindFreetype.cmake doesn't find debug library freetyped.lib

[Stuart Mentzer]

On 6/6/2016 6:02 AM, Rolf Eike Beer wrote:
> Stuart Mentzer wrote:
>> On 6/6/2016 4:21 AM, Rolf Eike Beer wrote:
>>> You wrote:
>>>> On 6/5/2016 4:26 AM, Rolf Eike Beer wrote:
>>>>> Am Samstag, 4. Juni 2016, 19:26:22 schrieb Stuart Mentzer:
>>>>>> On 6/4/2016 5:03 PM, Roger Leigh wrote:
>>>>>>> On 04/06/2016 20:47, Stuart Mentzer wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> FindFreetype.cmake is failing to find the debug library on Windows
>>>>>>>> because it is named freetype*d*.lib and freetyped isn't in the NAMES
>>>>>>>> list. Is there some variable I can set to get it found or can freetyped
>>>>>>>> get added to NAMES?
>>>>>>> See how other modules handle this, e.g.
>>>>>>>
>>>>>>> https://github.com/Kitware/CMake/blob/master/Modules/FindZLIB.cmake#L77
>>>>>>>
>>>>>>> Note the separate searches for the release and debug libs on lines 88-89
>>>>>>> and select_library_configurations on line 93.
>>>>>>>
>>>>>>> If you adapt FindFreetype to use the same pattern, it will handle this
>>>>>>> properly.
>>>>>> Thanks Roger. That looks the right way to do it. Seems odd that it is
>>>>>> handled for zlib but not for freetype. Is this something we can just ask
>>>>>> the developers to fix or would it be best for me to submit the fix to the
>>>>>> developers list?
>>>>> It's a reasonable addition, so if you can't come up with a patch yourself I'll
>>>>> have a look if I can do one next week which you can test.
>>>
>>>> A better(?) version of this is attached. Sorry -- just learning my way
>>>> around CMake.
>>>
>>> This looks quite good, but here are some remarks:
>> Thanks. Comments below...
>>> -I guess it was accidentially that you removed the list from CC?
>> No, I wasn't sure it was cool to send attachments to the general cmake
>> list. If I should I'm happy to forward these messages to it with
>> attachments.
>
> Yes, please do so. Also please send patch files as it's easier to review what you actually changed.
>
>>> -drop the FREETYPE_NAMES_* variables, just put the names in the find_library calls
>> Done.
>>> -please keep the old name for the release variable for backward compatibility. That means that you have to set/unset FREETYPE_LIBRARY_RELEASE around the call to SelectLibraryConfigurations
>> Not completely sure about this. I unset them after the
>> select_library_configurations call but my (shallow) understanding is
>> that the call sets FREETYPE_LIBRARY from them so I'm not sure what the
>> backward compatibility issue is.
>
> One can call "cmake -D FREETYPE_LIBRARY=..." from the command line and expect that this will end up in the cache as it did before. Otherwise that information would be lost on subsequent CMake runs in the same build directory.
>
> And don't unset() the variables used in find_library(), they should be accessible and will end up in the cache. Just add FREETYPE_LIBRARY_DEBUG to the mark_as_advanced() call at the bottom of the file.
Do you mean that I should use FREETYPE_LIBRARY instead of FREETYPE_LIBRARY_RELEASE?
>
>>> -if you want to de-messify that thing you could put all the HINTS and PATHS stuff into a variable as that is shared between all find_path/find_library calls
>> Done for PATHS. Since HINTS is just one item I didn't think it was
>> worth it. Maybe if the ENV process costs some time it might be though.
>
> You can put everything starting at the HINTS into that variable. It will be expanded before calling find_* so the argument list gets restored there. E.g. this is done in FindOpenSSL.cmake.
OK, but the PATH_SUFFIXES for the find_path and find_library calls are different so I can't include that in this uber-variable.
>>> -please add a short note in Help/release/dev/ for the changelog
>> It might be best for you to polish and submit this when you are happy
>> with it. I'm really a CMake noob!
>
> We're just changing that, no?
>
> Look here for an example:
>
> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/release/dev/FindOpenCL-imported-target.rst;h=259c745b0b39c3e83efa051f3dfbcc05787f9a5a;hb=refs/heads/next
OK, I can probably figure out how to submit a patch and dev note to the developers mailing list once we resolve these last few (?) issues.
>
> Greetings,
>
> Eike
Thanks for all the help.

Stuart