Hi Helmut, * Helmut Grohne <hel...@subdivi.de> [2024-09-09 18:38]:
And it will not solve cross-building for packages which interrogate numpy.get_include() directly, as SciPy does in its Meson build.But this is not a matter of numpy-config then. Would you mind detailing how numpy.get_include() works? Generally speaking, this sounds like a bad idea in any case.
The get_include() upstream implementation essentially boils down to
import numpy._core as _core
return os.path.join(os.path.dirname(_core.__file__), "include")
This is actually the One True Source from which everything else we
discussed derives, i.e., numpy-config is a wrapper script around
numpy._configtool, which computes --pkgconfigdir as
Path(numpy.get_include()) / ".." / "lib" / "pkgconfig"
Therefore, in order to keep everything consistent, my patch [1]
primarily changes the numpy.get_include() behavior and resorts to
the aforementioned $PKG_CONFIG hack in order to determine which path
should be returned.
This works because I *also* let python3-numpy-dev install a sane numpy.pc at /usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig (which in turn is the reason why I need to patch test_configtool in [1]: the assumption that pkgconfigdir points to the NumPy module tree no longer holds).
[1] https://sources.debian.org/src/numpy/1:2.1.1+ds-1/debian/patches/0008-Fix-path-configuration-to-work-with-Debian-specific-.patch/
> * Further split the package into two -dev packages.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).Don't rule it out so quickly. How bout this layout: python3-numpy-dev as it is proposed here would be kept as is. We'd move numpy-config to a new package python3-numpy-dev-config without python3-numpy depending on it. This will make some packages FTBFS, but we can fix each of them by adding the new package to Build-Depends, which is a relatively simple change not touching upstream stuff. As we touch them, we can also annotate python3-numpy with :native. Now as we cross build those packages, we'll install python3-numpy-dev-config:$DEB_HOST_ARCH and numpy-config --pkgconfigdir will simply produce /usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig as it knows that it is outputting for $DEB_HOST_ARCH. That way, what upstream recommends will likely just work as it is simply returning the default pkgconf search path. Stuff will break though if a package happens to require both ${DEB_BUILD_GNU_TYPE}-pkg-config and ${DEB_HOST_GNU_TYPE}-pkg-config and properly differentiates between them as the setting of PKG_CONFIG_PATH will override the prefix. I still expect a fair number of packages to just work this way.
Okay, I admit this is actually not such a bad idea if we are looking to keep numpy-config around. It does not solve the get_include() problem, but it makes numpy-config more robust.
But now that I have trapped you sufficiently deep in the rabbit hole of NumPy build tooling, do you have another good idea to make get_include() work?
Failing that, the PKG_CONFIG approach might be least bad, but that's really worth a README.multiarch or something then.Agreed. This is certainly something I should be mentioning somewhere. (-:
Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
signature.asc
Description: PGP signature
