Cross compiling client packages which require kconfig_compiler
or kconf_update want want the native tool, not the cross compiled variant.
The native tool is provided by a dedicated cmake variable.
Details
Diff Detail
- Repository
- R237 KConfig
- Branch
- master
- Lint
No Linters Available - Unit
No Unit Test Coverage
Yes, defining KF5_HOST_TOOLING should be enough, kconf_update will need to be exported with kconfigcompiler though, at the moment it's not.
Here's the android scripts for reference. https://cgit.kde.org/sysadmin/ci-tooling.git/tree/system-images/android/sdk
-DKF5_HOST_TOOLING=/opt/nativetooling/lib/x86_64-linux-gnu/cmake/
Can you point me to a working example for related cmake files specifing host tools ?
Is KF5_HOST_TOOLING support implemented for all required host tools, which are ( from https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:KF541/mingw32-kf5-filesystem/macros.mingw32-kf5?expand=1)
-DKCONFIG_COMPILER_EXECUTABLE=/usr/bin/%{_mingw32_target}-kconfig_compiler_kf5 \\\ -DKCONF_UPDATE_EXECUTABLE=/usr/bin/%{_mingw32_target}-kconf_update \\\ -DMEINPROC5_EXECUTABLE=/usr/bin/%{_mingw32_target}-meinproc5 \\\ -DCHECKXML5_EXECUTABLE=/usr/bin/%{_mingw32_target}-checkXML5 \\\ -DDOCBOOKL10NHELPER_EXECUTABLE=/usr/bin/%{_mingw32_target}-docbookl10nhelper5 \\\ -DDESKTOPTOJSON_EXECUTABLE=/usr/bin/%{_mingw32_target}-desktoptojson \\\ -DPARSETRIGRAMS_EXECUTABLE=/usr/bin/%{_mingw32_target}-parsetrigrams \\\ -DKATEHIGHLIGHTINGINDEXER_EXECUTABLE=/usr/bin/%{_mingw32_target}-katehighlightingindexer \\\ -DKGENDESIGNERPLUGIN_EXECUTABLE=/usr/bin/%{_mingw32_target}-kgendesignerplugin \\\ -DICEMAKER_EXECUTABLE=/usr/bin/%{_mingw32_target}-icemaker5 \\\
I'm happy to switch over to KF5_HOST_TOOLING if it is ready to use, but to not break working builds I would prefer to use XXX_EXECUTABLE as implemented by this patch
This patch is used at
https://build.opensuse.org/package/show/home:rhabacker:branches:windows:mingw:win32:KF547/mingw32-kconfig
https://build.opensuse.org/package/show/home:rhabacker:branches:windows:mingw:win64:KF547/mingw64-kconfig
for about a year without any problems
That doesn't mean it's the right solution :-)
I don't know much about all this, but it sounds like Aleix is saying that an existing solution also works and is simpler. Sounds worth investigating before "blindly" implementing a second way to do the same, even if it works...
I don't know much about all this, but it sounds like Aleix is saying that an existing solution also works and is simpler.
Please show me that solution with a working example
Sorry for the two spam comments, I had a freeze at phabricator web site.
Here's the android scripts for reference. https://cgit.kde.org/sysadmin/ci-tooling.git/tree/system-images/android/sdk
Ah I see, on Android the packages containing native tools are build. The package and their development packages including the cmake support files (xxxTargets.cmake) are then installed to a custom destination to which KF5_HOST_TOOLING is pointing to. Transformed to obs that would mean to use the runtime and development packages from https://build.opensuse.org/project/show/KDE:Frameworks5.
From working on the kf5 packages on obs I know that this approach has some issues:
- Not all required tools are installed with the package - I needed dedicated patches to let packages install them too (at least)
- From memory I remember that not all KF5 packages have working cross compile support
- obs uses currently another approach - there is a cross kf5 tools package providing all required tools installed in a custom location in one package (https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:KF547/mingw32-cross-kf5-tools/mingw32-cross-kf5-tools.spec?expand=1). This behavior is derived from the related xxx-cross-libqt5-yyy package. The native tools are installed as mingw helper tools and used in the cmake command line https://build.opensuse.org/package/view_file/home:rhabacker:branches:windows:mingw:win32:KF547/mingw32-kf5-filesystem/macros.mingw32-kf5?expand=1