Project

General

Profile

Patch #853

CMake: more flexible zlib detection

Added by Daniel Kaneider about 9 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
build
Target version:
Start date:
06 Oct 2012
Due date:
% Done:

90%

Estimated time:

Description

Hi,

the zLib path is pretty hard-coded into cmake, although the FindZLib would consider more options. Especially I don't want to relay on a directory 'zlib-1.2.7', since we link various libraries against zlib and are already using the 1.2.7.1 version.

Therefore my patch uses the cmake strategy to find zlib, and as a fall-back the old zlib path is used. In this way I can call CMake on the exiv2 project by calling for e.g.:

cmake.exe -G "Visual Studio 11 Win64" -DZLIB_ROOT=..\zlib-1.2.7-dev;..\zlib-1.2.7-dev\Release .

The script was tested with in-source exiv2 build on Win8, VS 2012 and CMake 2.8.9. Btw. the applied patch is against the 2890 svn version.

Best,
Daniel


Files

exiv2FlexZlib.patch (1.6 KB) exiv2FlexZlib.patch Daniel Kaneider, 06 Oct 2012 05:38

Associated revisions

Revision 2893 (diff)
Added by Robin Mills about 9 years ago

Fix. Issue: #853. More flexible way to detect and use existing Zlib libraries. Thanks Daniel for providing this patch.

History

#1

Updated by Robin Mills about 9 years ago

  • Status changed from New to Assigned
  • Assignee set to Robin Mills
  • Priority changed from High to Normal

Thank you very much indeed for this. And for the patch on #851.

It is very helpful indeed that you provide a solution for the issue that you have encountered. I'm still learning CMake and rather puzzled by FIND_LIBRARY on Windows.

You'll notice that in TODO-CMAKE, I've listed "Revisit searching for zlib, expat and iconv". I think you're pointing me in the right direction. In README-CMAKE, Gilles said "Use them only if you're prepared to fix them.". That's exactly what you've done and I appreciate your contribution.

I'll review this later in the weekend and submit.

If you have other thoughts and ideas about our CMake support, I will be very happy to accept your assistance and acknowledge your contribution.

#2

Updated by Robin Mills about 9 years ago

I've make 3 commits today for your fixes for #844, #852 and #853. Thank you for your contribution. I've also built the code with CMake on Linux/Mac/Cygwin and they all built and pass the test suite. So your fixes and suggestions have not caused issues to appear on non-MSVC builds.

I also used CMake to build on DevStudio 2010 Win64 and that didn't work. I haven't thought about MSVC/CMake since June, and it's time to give this more attention. From your comments, I believe you have MSVC/CMake working OK with DevStudio/2012. I will investigate the issues I encountered during this next week. It could be simply that I haven't followed my own instructions!

Thank you once more for taking the time to bring this to my attention and for providing patches. Your contribution is appreciated.

#3

Updated by Daniel Kaneider about 9 years ago

Thanks for your fast response!

CMake is quite a good tool, especially for Unix based systems. On Windows still many things don't work as smoothly as expected.

With the current exiv2 version I get the exiv2 and exiv2lib sub-projects compiled, with a bunch of errors. This means I get various .exe, .lib and .dll files, but some post-build events give some errors. I'm satisfied with that result, getting my files I need, but you are right. It doesn't work as it should.
The current point for MSVC is that no tests build. IMHO the testsuite might build and run on Linux, but it's not done correctly. I've already seen the source of this problems, but those might require bigger patches...

Since Windows is very strict regarding C++, from my experience it is the first platform to break compilation.

#4

Updated by Robin Mills about 9 years ago

  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 90

Daniel

Thanks again for all your splendid work on CMake/msvc. I'm going to mark this matter as resolved. Unless something arises from this, it'll be marked closed when at the end of the 0.24 development cycle.

#5

Updated by Robin Mills over 8 years ago

  • Status changed from Resolved to Closed

Fixed in 0.24.

Also available in: Atom PDF