2020.01.19 19:41 "Re: [Tiff] Warnings while building tools", by Bob Friesenhahn

wants do embed libtiff directly in their application and bypass

>     libtiff.so/dll <http://libtiff.so/dll>

or do anything custom, they're on their own.

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

Likewise. more detail on that would be useful.   Some

It was perhaps a poorly-selected term. In my limited experience, Makefiles generated by CMake require CMake to be present in order to run.

This caused some confusion for me in a non-tiff (Zstandard package to be precise) cross-compilation situation recently. The cross-compilation did succeed, but probably only due to how the source code was formulated.

With Autotools, it is not necessary for the person building the package to have Autotools installed in order to build.

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

The nmake Makefiles are formulated more similar to classic make so they can be used (by developers) to more easily integrate into a build system based on classic make. They might also be in some limited actual use.

> Is keeping Makefile.vc worth the additional maintenance overhead?  The

Obviously, it has not been consuming any maintenance overhead given that maintenance has not recently been done. ;-)

If after a week the community consensus is that the nmake Makefiles are of no value (nobody claims that they need them), then how about we get them working properly for the next libtiff release (seems really trivial) so there is a working point of reference and then stop distributing them in the libtiff releases thereafter?

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt