qt5base: fix dependencies and improve packaging resilience#105
qt5base: fix dependencies and improve packaging resilience#105titobrasolin wants to merge 1 commit into
Conversation
This update strengthens the qt5base package for diverse architectures: - Add +libatomic to core dependencies to prevent linking errors. - Add +libdrm to linuxfb and eglfs platform plugins. - Add @PACKAGE_qt5base-input-autodiscovery to libinput plugin dependencies. - Introduce wildcard checks in installation macros to prevent 'cannot stat' errors when specific plugins are disabled by the Qt configuration. - Fix --qpa configuration logic in Build/Configure. - Clean up and refresh existing patches, removing the obsolete 200-header-dep-fix.patch. Fixes: openwrt#73 Fixes: openwrt#74 Fixes: openwrt#104 Signed-off-by: Tito Brasolin <tito.brasolin@gmail.com>
| $(call Package/qt5base/Default) | ||
| TITLE+=platform linuxfb (plugin) | ||
| DEPENDS+=+qt5base-core +qt5base-gui +libfreetype +PACKAGE_qt5base-input-autodiscovery:libudev +PACKAGE_qt5base-plugin-input-libinput:libinput | ||
| DEPENDS+=+qt5base-core +qt5base-gui +libfreetype +libdrm +PACKAGE_qt5base-input-autodiscovery:libudev +PACKAGE_qt5base-plugin-input-libinput:libinput |
There was a problem hiding this comment.
Just double checking: libdrm is now unconditionally considered a dependency, because we do not (want to) support the legacy-framebuffer interface anymore, correct?
| $(call Package/qt5base/Default) | ||
| TITLE+=libinput (plugin) | ||
| DEPENDS+=+qt5base-core +qt5base-gui +libinput | ||
| DEPENDS+=+qt5base-core +qt5base-gui +libinput @PACKAGE_qt5base-input-autodiscovery |
There was a problem hiding this comment.
This feels kind of odd - why would libinput support depend on the input-discovery package being present?
There was a problem hiding this comment.
Hi Mirko, thanks for the feedback!
I added this dependency because, as far as I can tell, Qt5's libinput support has a strict pre-condition requiring libudev to be detected during configure.
Since udev is currently hard-disabled in this Makefile (see lines 35-36):
# hard disable udev support for now
CONFIG_PACKAGE_qt5base-input-autodiscovery:=
It seems that libinput fails to meet its requirements. In fact, a CI test I ran without the @PACKAGE_qt5base-input-autodiscovery constraint consistently fails with:
ERROR: Feature 'libinput' was enabled, but the pre-condition 'features.libudev && libs.libinput' failed.
I used the @ dependency as a sort of safety switch to keep the build green, but I'd be happy to hear your thoughts on a better way to handle these implicit Qt5 requirements!
There was a problem hiding this comment.
All info I can gather around this "hard disable" for now is this:
While it was both me creating the commit and the Qt-ticket, I don't recall the details anymore, other than "behaviour changed".
As a matter of fact, I never saw the reason for using libinput anyway.
evdev works fine with /dev/event* devices.
Maybe just purging the libinput-support/-package for good?
| $(if $(wildcard $(PKG_INSTALL_DIR)/usr/lib/qt5/plugins/egldeviceintegrations/libqeglfs-kms-egldevice-integration.so),$(call Build/Install/Plugins,$(1),egldeviceintegrations,libqeglfs-kms-egldevice-integration)) \ | ||
| $(if $(wildcard $(PKG_INSTALL_DIR)/usr/lib/qt5/plugins/egldeviceintegrations/libqeglfs-kms-integration.so),$(call Build/Install/Plugins,$(1),egldeviceintegrations,libqeglfs-kms-integration)) \ | ||
| $(call Build/Install/Plugins,$(1),platforms,libqeglfs) | ||
| ) |
There was a problem hiding this comment.
This feels like a huge pitfall and debug hell, where the build completes, but potentially with a different set of included files than expected.
As in: with the same qt5-config options, but different qt5-unrelated options (e.g. related to target), the qt5 build results in a different set of files.
That might be fine, if it would explicitly depend on a config option (e.g. "if not mips"), but simply not failing when files didn't get created/generated, sounds like the wrong approach and there's no way to tell why that happened, except files were not present for whatever reason.
2 participants
This update strengthens the qt5base package for diverse architectures:
Fixes: #73
Fixes: #74
Fixes: #104