Oops, sorry for the redundant reporting of this problem. I see now that it's already addressed by https://gitlab.com/libtiff/libtiff/-/merge_requests/434 <https://gitlab.com/libtiff/libtiff/-/merge_requests/434>
Thanks > On Dec 10, 2022, at 9:50 PM, Larry Gritz <[email protected]> wrote: > > Just a couple days ago, the master branch of libtiff saw the following change > as part of the big clang-format changes: > > @@ -1,4 +1,6 @@ > -#define TIFFLIB_VERSION_STR "LIBTIFF, Version 4.4.0\nCopyright (c) 1988-1996 > Sam Leffler\nCopyright (c) 1991-1996 Silicon Graphics, Inc." > +#define TIFFLIB_VERSION_STR > \ > + "LIBTIFF, Version 4.4.0\nCopyright (c) 1988-1996 Sam Leffler\nCopyright > " \ > + "(c) 1991-1996 Silicon Graphics, Inc." > /* > * This define can be used in code that requires > * compilation-related definitions specific to a > > > This change, by splitting the original #define TIFFLIB_VERSION_STR across two > lines, breaks CMake's bundled FindTIFF.cmake module, as you can see here: > > https://github.com/Kitware/CMake/blob/master/Modules/FindTIFF.cmake#L86 > > This means that any projects that use > > find_package (TIFF) > > and have any logic based on the setting of the CMake variable TIFF_VERSION > (including rejecting libtiff versions that not in the supported range) will > now fail, because it is unable to parse the version from this line, and > therefore cannot set TIFF_VERSION correctly. > > The simplest solution is to restore just tiffvers.h and exclude it from the > automatic reformatting. It might also be smart to put a comment in that file > advising that it is known that all downstream projects using CMake rely on > the specific formatting of that line and people shouldn't alter it. > > > -- > Larry Gritz > [email protected] > > > > > -- Larry Gritz [email protected]
_______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
