Add cross compile support for kconfig_compiler and kconf_update.
Needs ReviewPublic

Authored by habacker on Dec 17 2017, 8:31 PM.

Details

Summary

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.

Test Plan

cross-compiled client package

Diff Detail

Repository
R237 KConfig
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
habacker created this revision.Dec 17 2017, 8:31 PM
Restricted Application added a project: Frameworks. · View Herald TranscriptDec 17 2017, 8:31 PM
Restricted Application added a subscriber: Frameworks. · View Herald Transcript
habacker requested review of this revision.Dec 17 2017, 8:31 PM
bcooksley added a subscriber: apol.

I believe @apol was doing things along these lines for his Android work.

apol added a comment.Dec 17 2017, 11:31 PM

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

Restricted Application edited subscribers, added: kde-frameworks-devel; removed: Frameworks. · View Herald TranscriptAug 9 2018, 8:12 AM

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

This comment was removed by habacker.
This comment was removed by habacker.
habacker added a comment.EditedAug 11 2018, 5:43 AM
In D9387#180530, @apol wrote:

Yes, defining KF5_HOST_TOOLING should be enough, kconf_update will need to be exported with kconfigcompiler though, at the moment it's not.

that means host tooling support in kconfig is not usable yet

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:

  1. Not all required tools are installed with the package - I needed dedicated patches to let packages install them too (at least)
  2. From memory I remember that not all KF5 packages have working cross compile support
  3. 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