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-cr...@lists.debian.org > > Usertags: ftcbfs > > X-Debbugs-Cc: Debian CMake Team <pkg-cmake-t...@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
