1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1077673: debhelper: cmake buildsystem: update pkg-config passing me

    From Helmut Grohne@21:1/5 to Niels Thykier on Thu Aug 1 16:50:02 2024
    Hi Niels,

    (keeping full context for extended Cc)

    On Wed, Jul 31, 2024 at 10:18:10PM +0200, Niels Thykier wrote:
    Helmut Grohne:
    Source: debhelper
    Version: 13.16
    Tags: patch
    Control: affects -1 + cmake src:qt6-connectivity
    User: debian-cross@lists.debian.org
    Usertags: ftcbfs
    X-Debbugs-Cc: Debian CMake Team <pkg-cmake-team@lists.alioth.debian.org>

    cmake changed its way of communicating pkg-config again. The earlier
    method of passing -DPKGCONFIG_EXECUTABLE and later
    -DPKG_CONFIG_EXECUTABLE are no longer honoured in version 3.30. However,
    it now accepts an environment variable PKG_CONFIG. Let's also set that.
    I know this is getting ridiculous, but what is our choice?

    The attached patch goes slightly beyond and refactors a bit of code duplication. Hope that's ok.

    Helmut


    Hmm, is there any reason why we would not just always set the `PKG_CONFIG` environment variable for all build systems? We already set it
    (conditionally) for `make`.

    Do you know if there would be any harm in just doing it unconditionally for all build systems?

    I see two risks here. One is a risk of using the environment variable in
    an unconventional way. Say some package is using PKG_CONFIG for the
    build architecture instance and another variable for the host
    architecture one. As long as dh_auto_* only sets PKG_CONFIG when it is
    unset (as implemented in my patch), this can be worked around. I am not
    aware of any such case.

    The other risk is a lack of interface enforcement for the autoconf build system. We have taken measures to distinguish makefile from autoconf buildsystems such that for autoconf we expect configuration to be
    complete after the configure step and hence, we do not pass any of these
    things to make. Whilst more packages would build if we were to
    unconditionally export these variables, I think those are genuine bugs
    in the relevant build systems that we paper over and fixing them would
    be better. In essence, unconditionally exporting PKG_CONFIG would
    partially hide a bug class.

    Neither of these risks is a sufficiently strong reason to me to object.
    I am looping in debian-cross@l.d.o for further opinions.

    Helmut

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)