On 2/24/21 8:04 AM, Kai Pastor, DG0YT wrote: > Am 24.02.21 um 05:55 schrieb Sebastiaan Couwenberg: >> 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 > > From the mailing list post and its links I learn that > > a) actively maintained projects do fix reported build system issues > quickly. > > b) there is some confusion about dealing with CMAKE_BUILD_TYPE, NDEBUG > and reproducible paths. > > I would agree that many projects have shortcoming in how they use CMake, > partly due to past shortcomings of CMake and its documentation, partly > due to ignorance of cross-platform building and packaging. But IMO it > goes to far when you imply that CMake is to blame for issues with paths > and reproducibility.
CMake uses abolute paths, whereas autotools uses relative paths. How is CMake not to blame from issues that arise from that? > (Is there a Debian documentation for how to prepare CMake projects to > help with Debian multi-arch?) No that I know of, it would be good to have this in the upstream guide: https://wiki.debian.org/UpstreamGuide FWIW cmake/ProjInstallPath.cmake uses CMAKE_INSTALL_LIBDIR so it would do the right thing. >>> 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. > > Okay, so this covers your packaging point of view where autotools are > already available. But it doesn't align with my requirements as a > developer, and also not with my experience in single-arch > bundling/packaging third-party components for Android, macOS, Windows. > > (And I wouldn't even say that CMake is the best system for some purpose.) PROJ supports CMake in addition to autotools for platforms like Windows for similar reasons. You're not the only upstream who is unhappy that the proj package in Debian doesn't install the CMake bits, and as explained to support projects using CMake better PROJ should also install the cmake bits when it's built with Autotools. No one has been willing to implement that so far. That is the problem we need to solve. At least there is an upstream issue for it now: https://github.com/OSGeo/PROJ/issues/2546 >> 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? > > No, I don't think learning autotools and then teaching autotools to > provide CMake config files, possibly for multi-arch, is a good use of my > resources. But you may ask for patches for PROJ's CMake build system. > Multiarch if I can test/verify in an amd_64 environment. Since your more comfortable with CMake, maybe you can help upstream the pkg-config patch so that the Fedora package doesn't have to patch the CMake build to have proj.pc installed. We really need to get downstream projects more involved in PROJ development to help support their needs. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
