On 2/24/21 12:58 AM, Kai Pastor, DG0YT wrote: > Am 23.02.21 um 19:53 schrieb Sebastiaan Couwenberg: >> It's good practice to include the Find modules for any dependencies that >> are not part of cmake itself to not need upstream projects to install >> cmake modules for them. > > I think it is deprecated legacy practice, not good practice. Find > modules are poorly standardized, poorly maintained, and poorly tested. > It would be much better to provide PROJ config files as soon as > possible, instead of letting more developers start using PROJ with > non-standard find modules picked from random internet locations. > > I wonder if there is a blocker for building debian PROJ with CMake. I > build PROJ for Android, macOS, Windows from Debian tarballs - with > cmake, not using debian/rules. > https://github.com/OpenOrienteering/superbuild/blob/master/proj-7.1.1.cmake
Switching from autotools to cmake is generally a regression, cmake doesn't handle multiarch as well, and because it uses absolute paths instead of relative paths it hinders reproducible builds. See the recent discussion on the geos-devel lists for example: https://lists.osgeo.org/pipermail/geos-devel/2021-January/010078.html > The CMake build of PROJ doesn't seem to provide a pkgconfig file, but > even for mips64el, the single proj.pc looks much less complex than the > set of cmake config files, or the patch proposed for FindProj4.cmake. We're not going to switch to cmake for the proj package as long as autotools is supported, because that is the best build system from a packaging point of view. The best solution for downstream projects not wanting to include their own FindProj modules is to update the autotools build system to also install the cmake bits. Perhaps you can provide a patch for that which PROJ upstream can merge? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
