pygobject
Better runtime compatibility with alternative cairo build configurations
There was a gentoo request to build a pycairo variant without X support, even if cairo exposes it. The use case being that users are allowed to install cairo with or without X, and to only have one pycairo build that works with both.
This could be solved by forcing this at build time via something like -Ddisable-features=xcb_surface,xlib_surface for the various HAS macros: https://pycairo.readthedocs.io/en/latest/reference/constants.html#cairo-has, so we pretend as if cairo doesn't expose those features.
Another approach would be to detect those symbols at runtime, via dlopen()/dlsym() etc. I always thought that's not worth the effort, but maybe worth a try for the X things for starters.
Given how hard it seems to split cairo itself up into separate .so per backend, this could be pretty good.
There was a gentoo request to build a pycairo variant without X support, even if cairo exposes it. The use case being that users are allowed to install cairo with or without X, and to only have one pycairo build that works with both.
For a bit of extra background: it's not so much that we need one build that works with both, though that is a valid solution to my wish, but rather that we could use an "unopinionated about X" pycairo build that works with both. It's basically an extension of https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies but the current solution we use is that pycairo-without-X prevents you from installing cairo-with-X at all. So:
- binary builders can't build pycairo-without-X and serve the package if they installed cairo with X
- if you originally installed both without X, and then another package needs cairo-with-X but nothing needs pycairo-with-X, the dependency solver automatic resolution tries to automatically rebuild cairo with X "as a dependency", then runs off the side of a cliff and dies when another package depends on cairo-without-X and it cannot handle both requirements from different sides
The dlopen solution would work for this for the same reason it would help with cached wheels, indeed. The resulting build would be flexible in both directions (all pycairos compatible with all cairos), even though we'd be satisfied even for just one direction (pycairo-no-X compatible with all cairos).
