better approach for finding libproj

Issue #458 closed
Christoph Moench-Tegeder created an issue

reference: https://sourceforge.net/p/qlandkartegt/mailman/message/36639866/

In b047331 kiozen fixed build on Debian-based systems by having cmake patch in Find-files for libproj and quazip if a Debian system is detected. I believe this approach is not optimal: for the case of libproj, there are more systems than only Debian-based ones which build libproj with autotools (e.g. FreeBSD: https://svnweb.freebsd.org/ports/head/graphics/proj/Makefile?revision=498655&view=markup&sortby=date#l20 and Suse-based distributions: https://sourceforge.net/p/qlandkartegt/mailman/message/36645204/ ). Instead of trying to maintain a list of distributions (and still missing systems with local installations of libproj) I propose to use pkg-config for finding libproj if and after cmake's own mechanism fail. My patch from above-linked mail implements this - I'm creating this issue mainly to make sure it doesn't get lost in that mailing list archive.

For the case of libquazip: that issue only affects current Debian Stable aka "stretch", the Debian maintainers have since added the Find file: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778768 (a fixed version is included in Debian testing aka "buster" as of now). Providing a local Find file in qmapshack could create other problems on the newer Debian systems - I wonder if it wasn't better to require user-provided flags for libquazip in that case?

Comments (6)

  1. kiozen

    Sorry for late answer. But I needed some time to make up my mind.

    From my point of view the distributions should fix their packages. If a project provides a cmake file by any means it should be placed at the right location. Whatever the distribution considers as 'right'. Alternatively the library projects should be fixed if there is a proper location that is not based on distribution's religion.

    I don't think that fixing the build system of projects using a library is the right way. However there is quite a bunch of early adopters using Debian as a base for their Linux system. These users provide a valuable feedback on changes and new features and I do not want to lock them out or make their life more complicated just because Debian forgot the cmake files. That is why I created the patch. And I limited it's lifetime.

    Other distributions are more pragmatic. I talked to the maintainer of Fedora and he shares more or less my point of view regarding the responsibility of distribution. He added the missing files without any fuzz.

    Regarding your pkg-config patch I wouldn't like to introduce another project brewed workaround that is not mainstream. Let's do not forget the whole issue arises because I want to get rid of these self made files in the QMS source tree. Also I do not like that it affects several files introducing some additional flags. This is not how all the other libraries are handled. Let's stick to the intended procedure and let the distributions do their homework.

  2. Christoph Moench-Tegeder reporter

    For the libquazip case, I agree with your assessment ("Debian's libquazip packages are broken, we need a workaround until the fixed packages in the next debian release are in widespread use").

    With libproj, the issue is more complicated: here, it's libproj itself which does not provide the cmake files if it's being build with autotools. (I checked, that's still the case with proj 6.0.0). And it's not only Debian which builds proj with autotools, but also FreeBSD, NetBSD and that report from that Suse system (that leaves Redhat/Fedora derived systems with cmake?).

    And for that case we can use that pkg-config search, which I like much better than patching the build files live (and it's a standard way of finding stuff, not based on a list of distributions). Yes, cmake and pkg-config have a different philosophy of handling shared libraries (cmake just uses the full file name, while pkg-config has -l/-L flags). But until someone fixes proj and we get that into widespread use (and that takes time, given the release cycles of some of the distributions), we really should have something "better" than the patches based on that incomplete list of distributions.

  3. kiozen

    I know PROJ is really messing up the change from version 4 to anything else. It's not only a chaotic build system but also a completely broken API and no hint or clue how to restore the former behaviour. The authors are more interested in writing and documenting the new stuff leaving it to applications using PROJ to fix the mess. I had that discussion already on their mailing list.

    But I am completely reluctant to workaround the mess more than necessary messing up my own build system. Right now the fix is quite atomic to a single file. Easy to maintain and to remove after the timeout expired. And it will be removed.

    I think it makes more sense to send patches to PROJ to help them fix their mess instead of patching all applications that use PROJ. And for the meanwhile simply distribute the missing files along with the PROJ develop packages. That helps all projects using PROJ.

    As last resort, if self-compiling QMS is really a thing on your distribution and users can't easily get a package with the correct files then another distribution check is an option. But I doubt this is really the case. That Debian situation is quite special. Usually users simply want to have binary packages. And those compiling stuff know what they are doing.

  4. kiozen

    Yes, I know ;) And that's why FreeBSD users have up-to-date binaries. The self-compiling thing only arises on distributions that build on certain, outdated, Debian.

    Anyway, let's close that issue and hope all distributions get it right within the next year. The next big step will be switching to at least PROJ 6.1 as they promised to add a new function helping a bit to restore former pj_transform functionality.

  5. Log in to comment