[CMake] Cannot get automoc to work properly with recommended Qt5 support method

[Steve Lorimer]

Sounds like you have ended up at the same solution I did. I had trouble
getting the automated qt generation working, and in the end I made it
explicit

if(ARG_MOC)
qt5_wrap_cpp(MOC_OUT ${ARG_MOC})
endif()
if(ARG_RES)
qt5_add_resources(RES_OUT ${ARG_RES})
endif()
if(ARG_UI)
qt5_wrap_ui(UI_OUT ${ARG_UI})
endif()

add_library(
${ARG_NAME}
${LINK}
${ARG_SRCS} ${MOC_OUT} ${RES_OUT} ${UI_OUT}
)


On 20 October 2016 at 12:40, Alan W. Irwin <irwin at beluga.phys.uvic.ca>
wrote:

> Since I have gotten no response to my posts with this subject line, I
> assume automoc really is currently unsuitable for the case where the
> header that should be processed by moc is located in a different
> source-tree directory than the source file that includes that header.
> I temporarily worked around that issue with symlinks, but I then
> discovered that qt5_wrap_cpp produces exactly the same results as
> automoc (except for the identification of the header in its actual
> location as opposed to the symlink) and with no need for symlinks.  So
> I have abandoned automoc and used a custom target that invokes
> qt5_wrap_cpp instead, and that has allowed me to complete my update to
> the PLplot build system so that it replaces qt5_use_modules calls with
> the modern recommended target_link_libraries method of setting up use
> of Qt5.  And this change has also solved the issue of conflicts
> between plain and keyworded target_link_libraries calls that occurred
> with the qt5_use_modules based method.  So I am now satisfied with the
> PLplot build-system update, but I think automoc would be preferable to
> custom targets involving qt5_wrap_cpp if the above deficiency with
> automoc could be solved, so I will be pursuing that question further
> on the cmake-devel list.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20161020/2530f780/attachment.html>