2015.06.22 20:37 "Re: [Tiff] CMake support for building libtiff", by Roger Leigh

On 19/06/2015 14:53, Rhys Thomas wrote:

Hi Rhys,

Thanks for taking the time to give this a try!

(BTW, your name seems familiar from WYLUG! Though I've not been involved for several years after moving from York to Dundee.)

I have now completed the conversion and I have attached a set of patches to add CMake support (against the 4.0.4 beta release). This has been tested on the following platforms:

I'd be very interested in any feedback, particularly from Windows users.

  I'll follow up with a patch to disable the non-buildable components

tomorrow; you can just comment out the test/tools/contrib directories in the top-level CMakeLists.txt in the interim.

I have applied the previously attached patches to 4.0.4beta and tried a number of different configurations under Windows 7. On each occasion I did not change any of the settings available in CMake.

On my main Windows 7 machine I have tried to build on Visual Studio 2008 and 2012 (32 and 64 bit targeted on both, tried Debug and Release configurations) and have been unsuccessful in my attempts to build. The error messages seem to suggest that some header files are missing/inaccessible on my system (unistd.h being one of them). I have a lot of extra stuff set up in my Include and Library paths, including some parts of GnuWin32 which seems to be where the errors are coming from (zconf.h being one such source). Disabling Win32 file IO in CMake gets rid of a few of these errors.

I've just posted a new set of patches against 4.0.4. If you could possibly retry with them, it might have cleared up some of the issues (I've fixed a few header/type-related bits).

On a clean Visual Studio 2012 installation on another machine the results are much better: on all of the configurations that I tried (32/64 bit, Debug/Release) all but eight of the projects built successfully (is this the same number that you found? I did not comment out the lines that you suggested). I have not yet identified the projects that did not build correctly, however the output tiff library and dll files appear to have been generated. I have not yet used these output files in any of my applications. I have a clean Visual don’t Studio 2008 installation to try.

I haven't exhaustively tested every combination. It's on my list though--I've just been limited by time. It took a good while just getting the basic build and tests working, so haven't tested (on Windows) with separate zlib/jpeg/jbig at this point. I've tested the functionality on BSD/Linux/MacOS X to be sure it works with various combinations of no/some/all optional libraries being used. One other area which might need tweaking is the detection of the Debug/Release version of the libtiff.dll when running tests in case it's not sufficiently flexible.

If the new patches don't help here it would certainly be useful to have more concrete details of exactly what you are linking aginst, how those libraries were built etc. so I can try to reproduce locally. If they were built against a different version of the runtime that might cause problems? (I'm afraid I'm still a relative beginner to building on Windows since my native territory is Unix, so I'm still learning the ins and outs of the nastiness.)

In my opinion I would prefer the option for setting the JPEG include and library paths to be in the default rather than the advanced view of CMake-Gui. Is this an option that other people are worried about?

We are currently using the standard find_package() cmake functionality which marks these as advanced by default, so the current behaviour matches that used by all other cmake-using packages. However, it's certainly possible to remove the "advanced" setting with mark_as_advanced(CLEAR) if that is more generally desirable. libtiff is certainly a bit of a special-case with the 8/12-bit jpeg support.

Regards,