Adding CMake Finder for PySide and Shiboken

[wmayer]

So shiboken2 is version 5.11.2, built against Qt 5.9.5? Hrm, for some reason I thought the version had to match (though I can't actually recall reading that anywhere...)

No, it doesn't need to.

Since you're on ubuntu, though, I imagine the shiboken2 python module is not included in the installation?

No, it's not. But I downloaded the sources from the Debian mirror and built locally the shiboken2 stuff. This way I got the missing Python module.

In other words "python -c 'import shiboken2'" fails, correct? This is the 'issue' that I am trying to resolve, as the FindShiboken2.cmake finder I wrote relies on the python module.

By default yes. When changing to the build directory of shiboken2 it works.

[ezzieyguywuf]

No, it doesn't need to

Quite true. I've realized that the PySide team has included quite a bit of their documentation for building in setup.py (I guess this is maybe standard in the python distribution world?)

For PySide2 v 5.11.3 (which I explicitly checked, but I imagine 5.11.2 is probably similar), the commentary specifically notes that Qt 5.9 is supported.

Curiously, for PySide2 v5.12.4, it states that Qt 5.11+ is supported.

Probably something significant(ish) changed in the underlying Qt5 that necessitated this?

No, it's not. But I downloaded the sources from the Debian mirror and built locally the shiboken2 stuff.

Makes sense. That's what I'm doing now - except I downloaded the sources straight from the PySide2 team's website.

My plan is to make it work, then package it in a deb that I will upload to my ppa...although really, I guess it would need to go in the FreeCAD ppa.

This way, by having the FreeCAD version use this updated shiboken2 deb, we can ensure we get the python module, and thus my pull request can finally be used.

[wmayer]

BTW: https://forum.freecadweb.org/viewtopic. ... 86#p328486

[ezzieyguywuf]

BTW: https://forum.freecadweb.org/viewtopic. ... 86#p328486

♥ i could hug you

I'll follow that thread to see where it goes. If anything else, I may be able to provide some help or a diff for his deb package to resolve the issue. I ran into some similar hairiness when packaging OccWrappe and TopoManagers, which each include python bindings for both python2 and python3.

I don't remember exactly how I resolved it (i.e. the specifics of how the python module is named), but I did end up finding something that (I think) works...

[ezzieyguywuf]

On my virtual Xubuntu 18.04 using PySide2 and Qt 5.9.5 works without problems. The corresponding shiboken2/PySide2 version is 5.11.2

So shiboken2 is version 5.11.2, built against Qt 5.9.5? <snip/>

No, it doesn't need to.
<snip/>

I downloaded the sources from the Debian mirror and built locally the shiboken2 stuff. This way I got the missing Python module.

You succesfully built shiboken2 and pyside2 against Qt 5.9?

I can't see how... I'm currently trying to build pyside2/shiboken2 v 5.11.2 as you list above and, while the shiboken2 module compiles well, the pyside2 module errors out due to missing QRandomGenerator stuff, which looks like it was introduced it Qt 5.10.

Did you compile <b>only</b> the shiboken2 using this method?

Hrm, or I guess I could examine the build script for the pyside2 deb package. It probably had to do some patching to work right though...

[wmayer]

I only built shiboken2 as for PySide2 nothing was missing.

[ezzieyguywuf]

I have resolved my pivy issues, so I can now confirm that all tests pass using these two CMake finders.

I still expect the travis-ci to fail due to the issues discussed in this thread regarding the missing shiboken2 python module.

I'm working on trying to put together a patch for the debian package that will resolve this.

[ezzieyguywuf]

<snip>
functionality-wise there is one limitation that won't work any more with the Python modules approach:

Code: Select all

ui = FreeCADGui.UiLoader()
w = ui.createWidget("Gui::InputField")
w.show()
w.property("quantity") # when linking against the C++ libs this correctly returns the quantity, otherwise an error is raised

This is because using the C++ API of shiboken you can add your own converter classes but up to my knowledge there is no such mechanism to do it in Python.

I can confirm that this does not working using the FindShiboken2.cmake finder in this pull request.

Is this functionality needed? As it stands, the suite of FreeCAD tests did not find this issue.

If it _is_ needed, I can modify the finder to find the shared library instead of the python module. Or do we need both?

[ezzieyguywuf]

Update: upon further testing, it appears that if the python shiboken2 module is found, it necessarily means that the shiboken2 shared C++ library is also present in PATH. This is due to a dependence that the python module has on the C++ shared library. See below.

Code: Select all

# This shows the dependence
$ ldd shiboken2.cpython-36m-x86_64-linux-gnu.so
        linux-vdso.so.1 (0x00007ffff9b0f000)
        libshiboken2.cpython-36m-x86_64-linux-gnu.so.5.12 => not found
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/libstdc++.so.6 (0x00007fd2c1a2b000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fd2c16e5000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/libgcc_s.so.1 (0x00007fd2c14cd000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fd2c1102000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd2c2035000)

# Let's prove that the presence of the python module, and the ability to import it, means that the shared library is also present

$ ls
PySide2  pyside2uic  shiboken2  shiboken2_generator

# Since I'm not in a virtual environment, this import is simply pulling
# straight from the current working directory
$ python -c "import shiboken2"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/wolfie/Program/CAD_dev/pyside-setup/freecad_pyside2_builtfromscratch3_install/py3.6-qt5.12.4-64bit-release/lib64/python3.6/site-packages/shiboken2/__init__.py", line 4, in <module>
    from .shiboken2 import *
ImportError: libshiboken2.cpython-36m-x86_64-linux-gnu.so.5.12: cannot open shared object file: No such file or directory

# Activate the virtualenvironment which contains the python module
# as well as the shared library
$ workon freecad_pyside2_builtfromscratch

# Change to a different directory, so that python doesn't find the version of the python 
# module in the current working directory but instead searches its PATH
(freecad_pyside2_builtfromscratch)$ cd ..

# prove that there is no "shiboken2" python module in the current working directory
(freecad_pyside2_builtfromscratch)$ ls
site-packages

# try importing shiboken2 again, and this time print out its file location too
(freecad_pyside2_builtfromscratch)$ python -c "import shiboken2;print(shiboken2.__file__)"
/home/wolfie/.config/pyVirtualEnvs/freecad_pyside2_builtfromscratch/lib/python3.6/site-packages/shiboken2/__init__.py

[wmayer]

Is this functionality needed? As it stands, the suite of FreeCAD tests did not find this issue.

I do not remember where exactly in Path it's used but I once removed the converters and afterwards the Path devs complained about it.

If it _is_ needed, I can modify the finder to find the shared library instead of the python module. Or do we need both?

I don't consider this feature mandatory. For me it's sufficient to have a way to provide this feature and the people who need it must directly link against the shiboken2 library, then.

If it _is_ needed, I can modify the finder to find the shared library instead of the python module. Or do we need both?

As said above a CMake option must be provided where the user can decide to either use the one (C++) or the other approach (Python) to use the shiboken2 API.

I keep an eye on future shiboken2 versions. Maybe they will offer a way to also extend it with converters written in Python.