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
