2020.12.22 17:42 "Re: [Tiff] Naming of the 'libtiff' libraries in Windows - proposal", by Roger Leigh
When I wrote the CMake support, I made the naming completely backward compatible with the existing NMake Makefiles, as well as the CMake FindTIFF.cmake module. That’s the rationale for the current situation. And it’s also a convention adopted by a number of Windows libraries.
What is the specific problem with the existing naming conventions which you will fix by changing the naming? And what is the rationale for the new naming conventions?
The main risk with your suggestion is that it’s an incompatible change which could break existing use of libtiff on Windows. There could be thousands of projects out there which have relied upon the current naming scheme for many years which would be broken, and given the number of third-party applications and internal projects which use libtiff, that definitely needs factoring in. If you’re using Visual Studio, this could be present in the .vcxproj project files, and you will break those projects.
I think the naming change would actually be OK for the CMake FindTIFF except for the static suffix—that’s not handled as far as I’m aware.
If we were to change the naming conventions, I would prefer we went with the CMake default behaviour for naming libraries, and use another well known library as a reference implementation for how to do this, rather than invent our own new conventions. It might be that your suggested change already satisfies this, but I think this should be demonstrated with evidence of precedent for it in other projects.