schnitzeltony / meta-qt5-extra

OE layer for desktop environments based on Qt5 (KDE KF5+Plasma+Apps / lirios / lxqt / lumina)
MIT License
29 stars 32 forks source link

Qt5LinguistTools, cmake_lib.bbclass, SDKs #91

Open haadr opened 1 year ago

haadr commented 1 year ago

I'm trying to add qt linguist tools to an SDK so that they can be used during build time. I see that the paths to the lrelease etc binaries in the SDK's Qt5LinguistToolsConfig.cmake file are hardcoded to /usr/bin/lrelease etc whereas they should be redirected to the SDK's host part, I guess.

I see that meta-qt5 has this patch https://github.com/meta-qt5/meta-qt5/blob/master/recipes-qt/qt5/qtbase/0002-cmake-Use-OE_QMAKE_PATH_EXTERNAL_HOST_BINS.patch and I note that if Qt5LinguistToolsConfig.cmake were to use OE_QMAKE_PATH_EXTERNAL_HOST_BINS at "runtime" like the patch intends, ie when the SDK is used, then the path of lrelease etc would be set correctly. But, it seems there's this bbappend which removes this patch from SRC_URI and if I understand correctly then cmake_lib.bbclass should fix the path after do_populate_sysroot. However, this search-replace is only run on the qttool's sysroot, so if you install nativesdk-qttools to an SDK, it will contain the unpatched upstream version of the config.cmake file and the paths will be hard-coded. This would work on-target, but not as part of an SDK.

Masking the meta-qt5-extras qttools_git.bbappend is a work-around, but I assume that might mess up actually using qttools as a dependency of another recipe... am I doing it wrong :tm: or should cmake_bin.bbclass also patch the package files to be able to use qttools at "runtime", ie. when it's installed as part of for instance an SDK?