This is a follow up to the CMake mailing list thread with the subject line "Cannot get automoc to work properly with recommended Qt5 support method".
The deficiency I found with automoc is (as far as I can tell) it does not properly handle 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. For PLplot I have worked around this deficiency by abandoning use of automoc altogether and instead used custom targets that invoked qt5_wrap_cpp. But the whole concept of automoc is far superior to a custom target approach so this is a plea to the CMake developers to fix the above deficiency in automoc. To be specific here is the way I believe automoc should work. If #include "moc_<name>.cpp" is found in a source file under automoc control, then if moc_<name>.cpp could not be found in any of the include directories for the target, then search those include directories (including source-tree equivalents of build-tree include directories) for <name>.h, run moc on that file and place the result moc_<name>.cpp in the build directory corresponding to <name.h>. So the result is moc would be run just once on the correct header file with the moc_<name>.cpp result stored in one logical location no matter how many different source files in different directories have code with the above #include. My experiments showed that automoc currently falls short of this behaviour and only works if <name>.h is in the current source directory and I consider this deficiency to be a serious bug in automoc. Furthermore, the documentation of automoc needs improving to explicitly name the header file being processed by moc when encountering the above #include. Furthermore, the directories searched for that header file should be stated. For the current buggy state of automoc that would just be the current source tree, but once the bug was fixed it would be everything mentioned in include_directories and their source-tree equivalents. I hate to lose issues that can be trivially fixed on bug trackers, but if the above automoc fix and automoc documentation fix are not trivial, then I would be willing to incorporate the above and any further discussion here into an official CMake bug report. 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/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
