Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
On Tue, 23 Feb 2021 19:20:35 +0100 Sebastiaan Couwenberg wrote: On 2/21/21 4:32 PM, Bas Couwenberg wrote: > Control: forwarded -1 https://github.com/OpenOrienteering/mapper/issues/1214 > > Your package FTBFS with PROJ 8.0.0: > > CMake Error at /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message): >Could NOT find PROJ4 (missing: PROJ4_INCLUDE_DIR) > > It needs to be ported to use proj.h instead of proj_api.h which has been removed. Upstream already supports proj.h since v0.9.0. The attached patch updates cmake/FindPROJ4.cmake to make it work without proj_api.h and using proj.h instead. The patch has been applied in git. There is still a test failure, though. Refer to the attached buildlog for details. The test failure no longer occurs with 0.9.5-1. Graham, can you upload a new revision to fix this RC issue? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
Found this in the junk e-mails today... Am 23.02.21 um 19:20 schrieb Sebastiaan Couwenberg: There is still a test failure, though. Refer to the attached buildlog for details. This seems unrelated to PROJ 8.0.0. The failing test creates a QTemporaryFile, removes all permissions from the file via QFile::setPermissions(), and expects QFileInfo::readable() to return false for the path of the temporary file. This expectation seems to be not met. The test may be volatile, but worked so far, and I didn't have a better idea how to solve this in a portable way. If there is another change in the environment, hints are welcome. Best regards, Kai
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
Am 24.02.21 um 08:46 schrieb Sebastiaan Couwenberg: On 2/24/21 8:04 AM, Kai Pastor, DG0YT wrote: 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? If issue arise from the use of absolute path, it is okay to consider to CMake as a cause of this issues. But it doesn't mean it can always be blamed. Example: This Debian package was flagged to not build reproducible, due to absolute paths in binaries. But the installed artifacts were fully reproducible. The offending binaries were tests which were meant to be run in the build environment, nowhere else. 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. Did Fedora try to do that? We really need to get downstream projects more involved in PROJ development to help support their needs. Sure. I'm doing that for at least for PROJ, GDAL, Qt, Poppler. And I really want to use the small gains in build time CMake can offer e.g. with Ninja, when working with so many upstreams and platforms. We probably can agree that a packager (infrequent builds of a particular, rare changes to a clean build system, facing many leaf packages) and a developer (frequent builds, regular modifications to the build system, onboarding of new developers, facing many upstream packages) may have different requirements. Best regards, Kai
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
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
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
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. (Is there a Debian documentation for how to prepare CMake projects to help with Debian multi-arch?) 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.) 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. Kai
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
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
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
Am 23.02.21 um 19:53 schrieb Sebastiaan Couwenberg: A patch for that was just submitted to this bugreport. Thanks. 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 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. Kind regards, Kai
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
Am 21.02.21 um 16:32 schrieb Bas Couwenberg: Source: openorienteering-mapper Version: 0.9.4-2 Severity: important Tags: upstream ftbfs User: debian-...@lists.debian.org Usertags: proj-8.0 Control: forwarded -1 https://github.com/OpenOrienteering/mapper/issues/1214 Dear Maintainer, Your package FTBFS with PROJ 8.0.0: CMake Error at /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message): Could NOT find PROJ4 (missing: PROJ4_INCLUDE_DIR) It needs to be ported to use proj.h instead of proj_api.h which has been removed. Kind Regards, Bas Mapper source code is ported to use proj.h for modern PROJ. However, the embedded fallback FindPROJ4.cmake module isn't, and possible won't. Does Debian build PROJ 8.0.0 with cmake? Debian doesn't seem to provide the cmake config files for PROJ. openorienteering-mapper is meant to pick up these config files. If it finds a recent PROJ in that way, it won't use proj_api.h. Regards, Kai
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
On 2/23/21 7:47 PM, Kai Pastor, DG0YT wrote: > Am 21.02.21 um 16:32 schrieb Bas Couwenberg: >> Source: openorienteering-mapper >> Version: 0.9.4-2 >> Severity: important >> Tags: upstream ftbfs >> User: debian-...@lists.debian.org >> Usertags: proj-8.0 >> Control: forwarded -1 >> https://github.com/OpenOrienteering/mapper/issues/1214 >> >> Dear Maintainer, >> >> Your package FTBFS with PROJ 8.0.0: >> >> CMake Error at >> /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 >> (message): >> Could NOT find PROJ4 (missing: PROJ4_INCLUDE_DIR) >> >> It needs to be ported to use proj.h instead of proj_api.h which has >> been removed. >> >> Kind Regards, >> >> Bas > > Mapper source code is ported to use proj.h for modern PROJ. However, the > embedded fallback FindPROJ4.cmake module isn't, and possible won't. A patch for that was just submitted to this bugreport. > Does Debian build PROJ 8.0.0 with cmake? Debian doesn't seem to provide > the cmake config files for PROJ. That's an upstream issue with PROJ. When it's built with autotools it doesn't install the cmake bits, it only does so when it's built with cmake. 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. > openorienteering-mapper is meant to > pick up these config files. If it finds a recent PROJ in that way, it > won't use proj_api.h. Either way the FindPROJ4.cmake included in openorienteering-mapper needs to be updated to support PROJ 8: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=983254;filename=proj8.patch;msg=12 Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
