[CMake] CMake, QT5 and cross compilation
Hauke Krüger
krueger at ind.rwth-aachen.de
Sun Dec 20 05:06:23 EST 2015
Hi Dave, hi Jakob,
thank you for the responses to my question.
I finally found "my" solution: It seems that the creators of the cmake
Qt5 toolchain
have created some undocumented hooks:
In Qt5CoreConfigExtras, the moc is specified as an imported target:
>> if (NOT TARGET Qt5::moc)
>> add_executable(Qt5::moc IMPORTED)
>> set(imported_location "${_qt5Core_install_prefix}/bin/moc.exe")
>> _qt5_Core_check_file_exists(${imported_location})
>> set_target_properties(Qt5::moc PROPERTIES
>> IMPORTED_LOCATION ${imported_location}
>> )
>> # For CMake automoc feature
>> get_target_property(QT_MOC_EXECUTABLE Qt5::moc LOCATION)
>> endif()
The if-statement can be used to install another Qt5::moc imported target
if desired: In my cmake file,
I use
>> add_executable(Qt5::moc IMPORTED)
>> set(imported_location "/path/tp/moc")
>> set_target_properties(Qt5::moc PROPERTIES
>> IMPORTED_LOCATION ${imported_location}
>> )
>> # For CMake automoc feature
>> get_target_property(QT_MOC_EXECUTABLE Qt5::moc LOCATION)
to point to another moc location RIGHT before the Qt5 find_package
calls. The same works for uic and rcc.
Dave, you are right, I may run into a version conflict. I think there is
no other solution than making sure that
I use the same version of qt in both systems, host and target. And I am
not yet sure if I will run into linker problems later,
in particular with the rcc, since I am stuck now at another point
regarding my crosstool chain.
Plan B will be to follow your QEMU hints if I encounter additional
problems. I though about this but this does not really
feel to me as what I understand as a "cross-compile".
Thank you and best regards
Hauke
Am 19.12.2015 um 19:27 schrieb Dave Flogeras:
> On Thu, Dec 17,
>> So, here is my question: How can I overwrite the moc-executable (and uic
>> etc) path to use another moc version than the one found by the
>> find_package mechanism? If I use the moc which is part of my Linux host
>> PC rather than the arm compiled moc in the Raspberry file system, the
>> code generation should be fine, and afterwards, I will link against the
>> Raspberry Pi Qt5 libraries.
>>
> Hi Hauke,
>
> In the past, I have done this (wth Qt4) by generating, then hand
> editing the CMakeCache.txt to change the location of the moc
> executable to the native one. Now that reading your post made me
> re-visit this it seems to have two problems. First, with Qt5 finder,
> it doesn't seem to expose the moc location in the cache. Also I
> recall doing it the way I described works only if your native version
> is exactly the same as the arm version, otherwise you get errors like
> "this header was generated with a different version of Qt".... It
> always seemed pretty brittle.
>
> Another way that I do this, is by generating a toolchain file, which
> forces cmake to look only inside the RPi root directory. This means
> it will find the cross compiled moc executable. Then I have qemu set
> up with the Linux binfmt driver so that I can execute arm binaries
> 'natively'.. This is not trivial, and requires setting up a wrapper
> so that qemu can find the arm linker-loader etc. but you may be able
> to use this as a solution. I (loosely) followed this guide, modifying
> the wrapper to my system.
>
> https://gentoo-handbook.lugons.org/proj/en/base/embedded/handbook/index.xml?style=printable&part=1&chap=5
>
> Good luck.
>
> I'd also like to hear if there is a different solution to this problem.
More information about the CMake
mailing list