2020.01.19 16:53 "Re: [Tiff] Warnings while building tools", by Roger Leigh

We should not get rid of it because the CMake build is a "self serving" build which makes the assumption that the user is using the build product as is.

That's a reasonable one, isn't it? All other projects I can think of make the same assumption, and that applies to the autoconf build as well. If the user wants do embed libtiff directly in their application and bypass libtiff.so/dll or do anything custom, they're on their own.

I completely don't follow the "self serving" comment.

Likewise.  Some more detail on that would be useful.

CMake works just the same as the Autotools, but supports multiple build systems.  One of those is "NMake Makefiles".   It also supports Visual Studio, Ninja and Make.  Additionally, it can target MinGW, Cygwin or MSVC.  It should be able to cater for any common or not-so-common usage scenario on Windows.

What specific use case does Makefile.vc support which CMake does not already provide for?

Is keeping Makefile.vc worth the additional maintenance overhead?  The question originally asked indicates that it's already diverged somewhat for how CMake is doing things, and does bring into question how much ongoing testing it has, and whether it's building libtiff correctly with current releases.  It has zero CI test coverage.

The Makefiles produced by CMake can not be independently used, and they even need CMake available to work.

That's expected for a CMake build. CMake is pretty much mainstream to build a large number of open source projects on Windows. Not really a very exotic requirement in my opinion.

This is also exactly the same as the Autotools.  If there are changes to the build configuration files, it will regenerate the build files.  If there are changes to the source files, it will rebuild and relink the needed files.

I'd be much in favor in dropping the nmake build as well. libtiff doesn't need 3 build systems IMHO.

Agreed on all counts.

(But note that I have basically no experience building things on Windows, other than cygwin.)

my 2 cent:

 Microsoft C++ Library Manager vcpkg uses cmake to build tiff[1]

 [1] https://github.com/Microsoft/vcpkg/tree/master/ports/tiff

This is the primary way I'm now using libtiff on Windows in my projects. "vcpkg install libtiff:x64-windows" and you have the current libtiff release built with MSVC and ready to use.  A massive improvement on how things were, and is rightfully becoming the de facto way to get third-party library dependencies for development on Windows.  While end users are free to build libtiff for themselves, if you want an "official" build for Windows then I think this is the path we should recommend for most users.  It's simple, keeps you up to date with the latest libtiff release, and is massively simpler than building all the libtiff dependencies and then libtiff, since it takes care of that too.

I should also note that contributing fixes to vcpkg has been simple and painless.

Regards,

Roger