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.
-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.
-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
Greetings,
Eike
--
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
