I'm in the middle of some CMake updates to separate the build into components, and I ran into some unexpected behavior. PROJ_DATA_PATH is set to ${CMAKE_INSTALL_FULL_DATADIR}/proj at configure time, and I haven't provided any install prefix, so /usr/local/share/proj is embedded into the binary. However, CMake allows for changing the install prefix at install time. So, if I configure CMake with -DCPACK_GENERATOR_DEB=ON or something similar and run cmake --build ./build --target package, everything else that goes in a DATADIR like docs and man pages get installed to /usr/share/ but PROJ_DATA installs to /usr/local/share/proj because the install prefix has changed.
This raises the question: Could a path relative to the INSTALL_PREFIX be provided instead? I've been looking at filemanager.cpp and if I'm honest, I can't tell. I think whats happening is we automatically check the hard coded relative path ../share/proj, but PROJ_DATA_PATH must be an absolute path if provided.
If relative paths are allowed, the solution to my issue is easy, calculate the relative path between ${CMAKE_INSTALL_LIBDIR} and ${CMAKE_INSTALL_DATADIR} to use as my PROJ_DATA_PATH. If they aren't we should consider adding support for relative paths, as it would also help with the MacOS build as discussed in #4730. If we don't want to support relative embedded PROJ_DATA_PATHs, what if we changed the default behavior to not embed the PROJ_DATA_PATH unless the user provides a specific absolute path? We set the variable to the empty string by default and emit a warning that it wont be embedded because no path was given. The wild option would be to add a post install command that would patch the binary like Conda does as discussed in #4207.
I'm in the middle of some CMake updates to separate the build into components, and I ran into some unexpected behavior.
PROJ_DATA_PATHis set to${CMAKE_INSTALL_FULL_DATADIR}/projat configure time, and I haven't provided any install prefix, so/usr/local/share/projis embedded into the binary. However, CMake allows for changing the install prefix at install time. So, if I configure CMake with-DCPACK_GENERATOR_DEB=ONor something similar and runcmake --build ./build --target package, everything else that goes in aDATADIRlike docs and man pages get installed to/usr/share/but PROJ_DATA installs to/usr/local/share/projbecause the install prefix has changed.This raises the question: Could a path relative to the
INSTALL_PREFIXbe provided instead? I've been looking atfilemanager.cppand if I'm honest, I can't tell. I think whats happening is we automatically check the hard coded relative path../share/proj, but PROJ_DATA_PATH must be an absolute path if provided.If relative paths are allowed, the solution to my issue is easy, calculate the relative path between
${CMAKE_INSTALL_LIBDIR}and${CMAKE_INSTALL_DATADIR}to use as myPROJ_DATA_PATH. If they aren't we should consider adding support for relative paths, as it would also help with the MacOS build as discussed in #4730. If we don't want to support relative embedded PROJ_DATA_PATHs, what if we changed the default behavior to not embed the PROJ_DATA_PATH unless the user provides a specific absolute path? We set the variable to the empty string by default and emit a warning that it wont be embedded because no path was given. The wild option would be to add a post install command that would patch the binary like Conda does as discussed in #4207.