-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Qt6 support v2 #125
base: master
Are you sure you want to change the base?
Qt6 support v2 #125
Conversation
Plugins and libraries are supposed to be coinstallable leading to systems having both of them available at the same time. As a precaution to accidential mixups of libraries that lead to hard to analyze runtime issues due to ABI incompatibilities, always link publically against the versioned Qt library.
This should already be default config for Qt5.
This option name is a very common practice in many projects, make it easier to detect.
@dobey I am now looking into the coinstallability of qt5 and qt6 version of maliit and need a little bit of input what you desire. Specifically, how do you want to name the Qt6 version? from the list of installed files I will need to add a Qt6 suffix at least for the following artifacts:
So, for me the main question is, do you want to go with "maliit3" or "maliit6" or "maliit-qt6"? For KDE we typically use the Qt major version as suffix, but there we already had that suffix aligned with the respective Qt version. |
For Qt5 versions the name is not changed, only append 6 for Qt6 builds.
This introduces a 6 suffix for each maliit library basename and that only for Qt6 builds. Changing the library name allows to still used the project version for incompatible SONAME changes.
This is the state with the new patch set from today (please note, I am open to any changes, dropping of patches to makes less changes in order to allow less coinstallability)
Open points from my list:
|
08d3067
to
2598e27
Compare
@dobey Any comment from your side? With Qt5 going fully EoL in 5 months (May 2025) and later distros starting to consider dropping any remaining packages depending on Qt5 still etc it'd be nice to have a way forward here followed by Maliit component releases also compatible with Qt6 (it's been nearly 2.5 years since 2.3.x) :) |
CMakeLists.txt
Outdated
-DMALIIT_PLUGINS_DIR="${CMAKE_INSTALL_FULL_LIBDIR}/maliit/plugins" | ||
-DMALIIT_DEFAULT_HW_PLUGIN="libmaliit-keyboard-plugin.so" | ||
-DMALIIT_PLUGINS_DIR="${CMAKE_INSTALL_FULL_LIBDIR}/maliit${MALIIT_LIB_SUFFIX}/plugins" | ||
-DMALIIT_DEFAULT_HW_PLUGIN="libmaliit${MALIIT_LIB_SUFFIX}-keyboard-plugin.so" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-DMALIIT_DEFAULT_HW_PLUGIN="libmaliit${MALIIT_LIB_SUFFIX}-keyboard-plugin.so" | |
-DMALIIT_DEFAULT_HW_PLUGIN="libmaliit-keyboard-plugin.so" |
same 2 lines below too, otherwise maliit6-server
fails to load the plugin with e.g. the following since it's actually installed in /usr/lib/maliit6/plugins/libmaliit-keyboard-plugin.so
:
org.maliit.framework: bool MIMPluginManagerPrivate::loadPlugin(const QDir &, const QString &) Error loading plugin from "/usr/lib/maliit6/plugins/libmaliit6-keyboard-plugin.so" "The shared library was not found."
also connection/org.maliit.server.service.in
needs updating to take MALIIT_LIB_SUFFIX
int account since the executable is e.g. maliit6-server
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for the review! I just pushed the changes.
How to handle the dbus service file with respect to coinstallability is tricky though because this is the single file that produces a file clash between Qt5 and Qt6 version. Not sure if it is OK to just ignore it and let downstream figure out which one of them should be installed?
2598e27
to
dfd6d16
Compare
Is having Qt5/Qt6 be possible at the same time still relevant nowadays instead of just doing Qt6? |
As of early 2025 the sole remaining consumer of Qt5 maliit with everything at up-to-date versions I can think of is Lomiri (formerly Unity8, the Ubuntu Touch UI) which is also available in Debian repos, but now I wonder if even it could still bring up a Qt6 maliit-keyboard while the rest of the UI remains on Qt5 for the moment (hopefully not too long). @dobey was this the main consideration or something else? seeing the lack of timely releases if something must be pushed to a Qt5-compatible release in general it may make more sense to leave behind a compatible branch and otherwise move on similar to https://github.com/canonical/mir/tree/release/1.8, i.e. 2.3.x is Qt5 and 2.4.x is Qt6 or similar |
This is a work in progress setup that essentially is a cleaned up revision of #121 .
Done:
Next: