2020.01.21 19:23 "Re: [Tiff] Warnings while building tools", by Su
at least I am using the nmake / Makefile.vc feature for years within a Visual Studio /Windows environment, together with the same nmake / Makefile.vc feature of GeoTiff. The libtiff.lib and geotiff.lib are built easily with native Visual Studio tools, without the need to install any third party tools. Just call “nmake /f Makefile.vc” and that’s it.
Which third party tools would I have to install and what would be the call sequence on a standard Windows 10 with MS Visual Studio (e.g. 2015)?
> Von: Bob Friesenhahn
> Gesendet: So. 19.01.2020 20:41
> An: Roger Leigh,
> Kopie: firstname.lastname@example.org
> Betreff: Re: [Tiff] Warnings while building tools
wants do embed libtiff directly in their application and bypass
>>> libtiff.so/dll " target="_blank">http://libtiff.so/dll>
or do anything custom, they're on their own.
I completely don't follow the "self serving" comment.
Likewise. detail on that would be useful. Some more
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?
> Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt>
> -----Ursprüngliche Nachricht Ende-----