Notes |
|
(0032828)
|
Rolf Eike Beer
|
2013-04-15 07:12
|
|
Please use SelectLibraryConfigurations module. |
|
|
(0032831)
|
Jochen Wilhelmy
|
2013-04-15 09:23
|
|
Now I used SelectLibraryConfigurations.cmake and used FindBZip2.cmake as a template.
I also patched SelectLibraryConfigurations.cmake because it duplicated the libraries. I replaced
set( ${basename}_LIBRARY )
which restores a cached entry from a previous run of cmake by
set( ${basename}_LIBRARY "" ) |
|
|
(0032832)
|
Jochen Wilhelmy
|
2013-04-15 09:24
|
|
which one is correct
ZLIB_INCLUDE_DIR
or
ZLIB_INCLUDE_DIRS? |
|
|
(0032847)
|
Rolf Eike Beer
|
2013-04-16 02:37
|
|
The one you search for using find_library() is the singular one. The one to include is the plural one, because it may contain multiple things (different configurations like in this case, or just the library and it's dependencies).
You do not need to if-guard the find_library() calls. If the output variable of find_library() is already set it simply does nothing.
You must not remove the ZLIB_ROOT code, as we need to keep compatibility with older releases.
Can you describe the problem in SelectLibraryConfigurations a bit more? Under which circumstances does it duplicate entries? |
|
|
(0032851)
|
Jochen Wilhelmy
|
2013-04-16 04:36
|
|
so exposing ZLIB_INCLUDE_DIRS and ZLIB_LIBRARIES (both plural) in FindZLIB.cmake is correct? Some FindXXX.cmake scripts expose XXX_INCLUDE_DIR (e.g. FindBZip2.cmake).
The problem in SelectLibraryConfigurations appears in the second run of cmake where set( ${basename}_LIBRARY ) sets the variable to the value of the first run and not to empty.
so after the first run if ${basename} is ZLIB then ZLIB_LIBRARY is
optimized;zlib.lib;debug;zlibd.lib
after the second run ZLIB_LIBRARY is
optimized;zlib.lib;debug;zlibd.lib;optimized;zlib.lib;debug;zlibd.lib
Is it possible that you fix FindZLiB.cmake, FindPNG.cmake, FindJPEG.cmake and findTIFF.cmake to use SelectLibraryConfigurations because I may break the one or other compatibility requirement. But I can give it another try ;-) |
|
|
(0033028)
|
Rolf Eike Beer
|
2013-05-11 09:16
|
|
Well, Modules/readme.txt has the way it should be, and we try hard that it becomes that way on any new modules or if modules need reworking. But a harder requirement is backwards compatibility, so if old modules have a different behaviour they will keep this (maybe getting the new one additionally).
I'll look into the SLC issue. |
|
|
(0033149)
|
Stephen Kelly
|
2013-05-29 02:51
|
|
The SLC issue may have been fixed with commit a2099a8e8d2b97d2a2f91cbc06a4078f7c5b7139 |
|
|
(0034334)
|
Stephen Kelly
|
2013-11-02 11:36
|
|
Is there anything blocking this now? |
|
|
(0042267)
|
Kitware Robot
|
2016-06-10 14:28
|
|
Resolving issue as `moved`.
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page. |
|