pyside2 cmake target file is only compatible with python3

[efferre79]

I am using your ebuilds to install pyside2 and shiboken2, thanks for your effort.

When using python2 to build a package which uses pyside2 I get a reference to /usr/lib64/libpyside2-python3.6.so.5.12.5 which is of course wrong. After investigating a little bit I have noticed /usr/lib64/cmake/PySide2-5.12.5/PySide2Targets-gentoo.cmake which references always to that library. In comparison /usr/lib64/cmake/Shiboken2-5.12.5/Shiboken2Targets-gentoo.cmake seems to use the PYTHON_CONFIG_SUFFIX variable to select the python version.

[efferre79]

actually it seems that also in /usr/lib64/cmake/Shiboken2-5.12.5/Shiboken2Targets-gentoo.cmake there is a problem with the Shiboken2::shiboken2 binary target which always points to /usr/bin/shiboken2-python3.6 while the library target Shiboken2::libshiboken looks fine

[efferre79]

On my system I have the following configuration, PYTHON_TARGETS="python2_7 python3_6 -python3_5 -python3_7 -python3_8" used to build pyside2 and shiboken2

[leycec]

The linkage pain continues. I appreciate the tortuous writeup. You are, of course, absolutely right about absolutely everything.

what we do now, bro

If I'm reading your exhaustive analysis correctly, we'll need to patch:

• shiboken2 ebuilds to globally replace patterns matching shiboken2-python[[:digit:]]\+\.[[:digit:]]\+ with shiboken2${PYTHON_CONFIG_SUFFIX} in /usr/lib64/cmake/Shiboken2/Shiboken2Targets-gentoo.cmake.
• pyside2 ebuilds to globally replace patterns matching pyside2-python[[:digit:]]\+\.[[:digit:]]\+ with pyside2${PYTHON_CONFIG_SUFFIX} in /usr/lib64/cmake/PySide2/PySide2Targets-gentoo.cmake.

Well, that's certainly doable. Three alcoholic cheers for that. 🥂

why this still broke, bro

Allow me to shamefully explain why this is still painfully broken. First and foremost, upstream doesn't officially support our use case under Gentoo. The Qt Company only ever intended Shiboken2 and PySide2 to be statically built against a single Python version. We, of course, need to dynamically build both against arbitrarily many Python versions. Technically, this is feasible with extreme sed munging. Obviously, we're not there yet. ^{Insert </megasigh> here.}

Secondly, we have no idea how to test this functionality. Our PySide2-based multiphysics biology simulator only dynamically imports from the high-level PySide2 package at Python runtime rather than statically linking against lower-level shared library objects at C++ compilation time. Since this is our main test case, the /usr/lib64/lib{shiboken2,pyside2}-*.so*, /usr/lib64/pkgconfig/{shiboken2,pyside2}*.pc, and /usr/lib64/cmake/{Shiboken2,PySide2}/*.cmake files are all untested. ^{Don't crucify me.}

when this gonna end, bro

So, thanks a heap overflow for testing this for us all! Brave bleeding-edge victims volunteers are always more than welcome.

We'll get this patched up for you in a jiffy. ^{Jiffy lube not included.}

[leycec]

Bam! The Shiboken2 and PySide2 ebuilds have been bumped up to shiboken2-5.12.5-r2 and pyside2-5.12.5-r2. If you could manually test both on your end and verify that they resolve your project's issues and bring balance back to the Qt Force, I will happily cry man tears of salty joy... yet again. 😂

[efferre79]

I confirm that your latest ebuild fixes my problem, thanks!