summaryrefslogtreecommitdiff
path: root/tests-clar/diff/patch.c
diff options
context:
space:
mode:
authorThomas Rast <trast@inf.ethz.ch>2013-06-19 13:36:59 +0200
committerThomas Rast <trast@inf.ethz.ch>2013-06-19 14:02:11 +0200
commitc41281ad3af420bcfe4afae6acdbe95039290525 (patch)
tree5d86308708a79e1232919f3db1239c387d344e73 /tests-clar/diff/patch.c
parent824cf80f061ab31f45c94576f9e75533201a4578 (diff)
downloadlibgit2-c41281ad3af420bcfe4afae6acdbe95039290525.tar.gz
CMakeLists: fix zlib linker setup
b53671a (Search for zlib unconditional, 2012-12-18) changed things around to always (even on windows, that's what the subject refers to) call FIND_PACKAGE(ZLIB). However, it did not correctly handle the case where ZLIB_LIBRARY is cached, either by the user setting it manually or by an earlier search. In that case, the IF(ZLIB_FOUND) would not trigger (that variable is not cached) and we'd instead use the built-in version. 000e689 (CMake: don't try to use bundled zlib when the system's path is in the cache, 2013-05-12) tried to fix that, but it actually made the problem worse: now with ZLIB_LIBRARY cached, _neither_ of the blocks would execute, resulting in a linker error for me when trying to build such a doubly-configured setup. To fix the issue, we just trust CMake to do the right thing. If ZLIB_LIBRARY is set (either from user or cache) then the find_library in FindZLIB.cmake will use that instead of searching again. So we can unconditionally (for real this time) call FIND_PACKAGE(ZLIB), and just check its result.
Diffstat (limited to 'tests-clar/diff/patch.c')
0 files changed, 0 insertions, 0 deletions