PythonQt / Discussion / Open Discussion: Library names and versions when building for Qt 5

Erik Lundin - 2017-05-28

Hello,

I'm currently trying to update the Debian package for version 3.1 of PythonQt, which means building for Qt 5 (only) and using qmake instead of cmake.

The .so files created now are by default called libPythonQt.so.1.0.0 and libPythonQt_QtAll.so.1.0.0. The library in the current Debian package libpythonqt3.0 is called libPythonQt.so.3.0.0. How about renaming the libraries to something like libPythonQt5.so.3.1.0 and libPythonQt5_QtAll.so.3.1.0 to indicate the broken ABI? Otherwise the major SOVERSION needs to be bumped somehow.

Attached are two patches to make building work for me (Linux Mint 18.1, Qt 5.5).

Could somebody please add a tag (and maybe also branch) for version 3.1? Currently, the only sign of a 3.1 version is the zip file, and it's not obvious which revision it corresponds to. Is it 432?

Last edit: Erik Lundin 2017-05-28

disable_missing_qt54_modules.diff

fix_format_security_error.diff

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Florian Link - 2017-05-29

I would suggest releasing the current svn trunk as 3.2, since there have been many fixes on trunk and trunk is quite stable (we use it on a daily basis with >100 people). Regarding the naming, I am open to that, maybe using 5 as a postfix is really the best solution. The only thing that I see coming is that PythonQt also supports Python 3, so if you want to distingish that as well, we would need to add another marker for the Python version Python3Qt5 looks ugly, though...
What do you think?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Erik Lundin - 2017-05-29
  
  I think an extra "-python3" like below would work, in order to not break apart the "PythonQt" name which signals where the library belongs.
  
  Python 2
  libPythonQt5.so
  libPythonQt5_QtAll.so
  
  Python 3
  libPythonQt5-python3.so
  libPythonQt5-python3_QtAll.so
  
  Or, to be more consistent with what's normal among other Linux libraries: only use lowercase and dashes:
  
  Python 2
  libpythonqt5.so
  libpythonqt5-qtall.so
  
  Python 3
  libpythonqt5-python3.so
  libpythonqt5-python3-qtall.so
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Florian Link - 2017-05-30

Looks good to me, except that I would add the Python version to the Python 2 version as well. And should't it be python27 and python36, so that it is clear against which version the library was built?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Erik Lundin - 2017-05-30
  
  I agree; -python27, -python36 etc. sounds good to me.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Erik Lundin - 2017-06-04
  
  Here is a patch that changes the library name generation to
  
  ~~libPythonQt5-python2.7.so~~
  
  ~~libPythonQt5-python2.7_QtAll.so~~
  
  libPythonQt-Qt5-Python2.7.so
  
  libPythonQt-Qt5-Python2.7_QtAll.so (alt 1)
  
  libPythonQt_QtAll-Qt5-Python2.7.so (alt 2)
  
  I'm using PYTHON_VERSION, so for Windows it will be -python27, but I guess that's fine? The placeholder "pythonXY" is needed since PYTHON_VERSION is declared in python.prf, and therefore isn't available when TARGET is declared in src.pro and PythonQt_QtAll.pro.
  
  I also specify the version 3.2.0 in common.prf to have the correct library versions generated rather than just 1.0.0.
  
  Edit: Added missing 5 in libs for Windows. Also separated out "qt5" - In my opinion it is more clear.
  
  There are two versions of the patch: one that places "-Qt5-Python2.7" before "QtAll" and one vice versa. I think I prefer the latter (alt 2 above). What do you think? Some other feedback?
  
  Last edit: Erik Lundin 2017-06-04
  
  qt_and_python_versions_in_library_name.diff
  
  qt_and_python_versions_in_library_name_reordered.diff
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Florian Link - 2017-06-06

I added your patch to svn trunk. Naming is fine with me, although adding the extra Qt5 seems a bit redundant.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Erik Lundin - 2017-06-06
  
  Thank you. I will continue the work to get a new version into Debian, but until 3.2 is released, the packaging will be based on version 3.1. If 3.2 is released before the Debian review is done, I could use that instead.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - tom - 2017-06-06
    
    Would it be possible to add the QtAll library to the debian packaging?
    I'm stuck to manually build that and add a
    
    list(APPEND CPACK_DEBIAN_PACKAGE_CONFLICTS "libpythonqt2.1, libpythonqt3.0")
    
    in my cpack generator
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Erik Lundin - 2017-06-06
      
      Yes, that's the idea. The advice I got on one of the mailing lists was to put the libraries for QtAll extension in a separate binary package. The packages I have in mind now are
      
      libpythonqt-qt5-3
      
      libpythonqt-qt5-dev
      
      libpythonqt-qtall-qt5-3
      
      libpythonqt-qtall-qt5-dev
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Florian Link - 2017-06-06

I can do a 3.2 release right away, there are no pressing issues that need to be fixed.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Florian Link - 2017-06-06

Do you need anything else to be part of 3.2?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Erik Lundin - 2017-06-06
  
  No, I'm fine with a 3.2 release in the current state. The patches I supplied in the first post only fix stuff in generated code, and to fix those issues properly might be difficult.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Florian Link - 2017-06-06

I just released it and also added a branch at code/branches/3.2

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Library names and versions when building for Qt 5

Dynamic Python binding for Qt Applications

Forums

Help

Library names and versions when building for Qt 5

Library names and versions when building for Qt 5

Dynamic Python binding for Qt Applications

Forums

Help

Library names and versions when building for Qt 5 document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

Library names and versions when building for Qt 5