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
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
