libgeotiff/CMakeLists: Propegate proj usage requirements publically - #143
johnwparent wants to merge 1 commit into
Conversation
Signed-off-by: John Parent <john.parent@kitware.com>
fallenmi
left a comment
There was a problem hiding this comment.
AI disclosure: I used OpenAI Codex to assist this review; I verified the result locally against exact head e6b94c0c6ec27b91a678d35246c07f0d1fa9a8ca.
The new public link interface is not loadable from an installed shared GeoTIFF package. PROJ::proj is now written into geotiff_library's INTERFACE_LINK_LIBRARIES, but find_dependency(PROJ) is still appended to CONFIG_PRIVATE_DEPENDENCIES; the generated package config executes that block only when BUILD_SHARED_LIBS is off.
I generated and staged the installed CMake package files from exact base ffafadec and this head, then configured a minimal downstream project that only calls find_package(GeoTIFF) and links geotiff_library. The base config/generation passes, while this head fails in geotiff-depends.cmake because PROJ::proj was never defined. The current-master merge ref cc828cf fails identically. The static-package path passes because its config does execute the private dependency block, and moving PROJ to CONFIG_PUBLIC_DEPENDENCIES makes the shared-package oracle green.
Please emit find_dependency(PROJ) as a public dependency and add an installed shared-package consumer regression alongside this link-visibility change.
geo_keyp.h is a public header that includes proj.h, so PROJ must be a PUBLIC cmake dependency so that downstream targets (utilities, consumers) can find proj.h.
See spack/spack-packages#5368 for the use and testing of this patch (tested on MacOs, Linux, and Windows)