Hi Helmut, * Helmut Grohne <helmut@subdivi.de> [2024-09-09 07:36]:
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.
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.numpy-config is actually in python3-numpy, not in python3-numpy-dev, so it is not MA: same. Without $PKG_CONFIG, it will simply return the configuration for python3-numpy's own architecture, which is arguably not surprising behavior. But let's examine the alternatives:
Given that I'm not a big fan of foo-config scripts in the first place, I'm very tempted. The NumPy approach is really contrived, as they want you to runThings we did for other packages: * Delete foo-config and patch all downstreams to use pkgconf.
export PKG_CONFIG_PATH=$(numpy-config --pkgconfigdir)
NUMPY_INCLUDE_DIR=$(pkg-config numpy --cflags)
This is probably a workaround for the limitations of setuptools; you
can create globally visible script entrypoints, but you cannot
install .pc files to a globally visible location.
On the other hand, I'd *really* like to avoid introducing yet another Debianism to such a popular package in the Python ecosystem, and the numpy-config approach is prominently featured in the upstream docs, so we can assume it will be adopted and be a potential cause for quite a few bug reports.
* 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.That would work, but would still require lots of patches in downstream packages, which are likely to hardcode numpy-config in their build scripts. And it will not solve cross-building for packages which interrogate numpy.get_include() directly, as
SciPy does in its Meson build.
Hard pass. I'm not going to atomize the package further (and given that numpy-config is not in python3-numpy-dev, it is probably not needed anyway).* Further split the package into two -dev packages.
Counter-proposal: If $PKG_CONFIG still seems too iffy for your taste, would you feel better if we defined a NumPy-specific environment variable such as NUMPY_EXTENSION_ARCHITECTURE? Or is there yet another way how we could determine the desired architecture in a cross-build setting?
Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
Attachment:
signature.asc
Description: PGP signature