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
