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
