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. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake