Re: Bug#1076236: python3-numpy: python3-numpy doesn't support cross-building well

[Helmut Grohne <helmut@subdivi.de>]

Hi Timo et al,

On Sun, Sep 08, 2024 at 11:17:02PM +0200, Timo Röhling wrote:
> The cross build support relies on pkg-config to select the correct host
> architecture via "/usr/lib/ARCH/pkgconfig/numpy.pc", so I patched all
> relevant API entrypoints (numpy-config, numpy.get_include()) to query
> $PKG_CONFIG or pkgconf. As long as cross-builders stick to the documented
> API to query the correct NumPy include path, everything will work
> out-of-the-box.

I vaguely take issue with this approach. It was tried elsewhere and it
is an annoying failure mode. Generally speaking. foo-config tools should
not reside in M-A:same packages. We expect that a foo-config tool
behaves for the architecture of the package it was requested for.
Things we did for other packages:
 * Delete foo-config and patch all downstreams to use pkgconf.
 * Enhance foo-config to parse its $0 and extract the triplet from that.
   This approach makes AC_PATH_TOOL and most pre-meson/cmake users
   likely are using autoconf.
 * Further split the package into two -dev packages. In this case, we'd
   move numpy-config into a another M-A:no -dev package that depends on
   python3-numpy-dev and doesn't contain much but numpy-config. In
   particular, python3-numpy must not depend on the new package and
   downstream packages requiring numpy-config must add the new
   dependency. This is to allow coinstallation of python3-numpy and the
   new -dev package for different architectures. This approach tends to
   make reverse dependencies (that do not require numpy-config for two
   architectures simultaneously) just work for cross compilation.

While consuming a PKG_CONFIG variable in numpy-config is creative, I
count it as a violation of the principle of least surprise. In many
build environments PKG_CONFIG is not exported, so this leads to a
cross-specific need for patching many packages.

Helmut