On 2016-10-22 19:49+0200 Sebastian Holtermann wrote: [...]
Actually I made an implementation in 3.6.0 that generated the moc files in the a build tree subdirectory correspoding to the header path.But that blew up on some projects because the generated paths got too long for some compiĺers. That implementation was theefore reverted.In 3.7 there is a new approatch that generates the moc files in ${CMAKE_BINARY_DIR}/ ${TARGETNAME}_automoc.dir/ ${HEADERNAME}_${HEADERPATHCHECKSUM}.cppThis ensures that the paths don't get too long and that there won't be any name collisions.
Hi Sebastian: After a substantial break to finish off a different project, I have now had a chance to return to the present topic using my attached test_automoc project. (Also available in the cmake/test_automoc subdirectory of the PLplot git master branch that can be accessed at <https://sourceforge.net/p/plplot/plplot/ci/master/tree/>.) The project builds 6 separate simple Qt5 applications that #include a header that needs moc processing. The only differences between the source code files for the various executables is the name and directory location of that #include'd file and the various instructions given to automoc (and in one case qt5_wrap_cpp) to process that file. With that test project, I now confirm (sorry about the noise to the contrary before) that automoc does use the approach you mentioned above for CMake-3.7.0 to reduce the name collisions that occur for that same project for earlier versions of CMake. Concerning the collisions still expected for 3.7.0, the automoc documentation (see <https://cmake.org/cmake/help/v3.7/prop_tgt/AUTOMOC.html>) states the following: "However, if multiple source files in different directories do this [i.e., contain an "#include "moc_<headerbasename>.cpp" when the header name is <headerbasename>.h] then their generated moc files would collide. In this case a diagnostic will be issued." For the life of me, I cannot find a way to generate that diagnostic. Instead, three different targets (two targets concerning the same implementation code and header in the same directory and a third target for a copy of that same implementation code and header in a different directory) generate at build time a file named moc_test_q_object.cpp in the same build directory at different times. This is a clear example of a three-way name collision, but CMake does not issue a diagnostic for any of these targets concerning that collision contrary to the above documentation. Could you please take a look at the three last executables configured for this test case (helloworld_automoc_same_include, helloworld_automoc_same_include1, and helloworld_automoc_same_include2) to see why that collision diagnostic is not being issued with cmake-3.7.0? Better yet, of course, would be to solve these remaining name collisions completely by using a modification of your idea above, i.e., for this special case where users implementation code contained #include "moc_<headerbasename>.cpp" then moc should generate the file ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir/${HEADERPATHCHECKSUM}/moc_${HEADERNAME}.cpp Note, the generated moc file has the name expected by the #include so I believe this idea would work so long as automoc automatically appended ${CMAKE_BINARY_DIR}/${TARGETNAME}_automoc.dir/${HEADERPATHCHECKSUM} to the target INCLUDE_DIRECTORIES property. 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 __________________________
test_automoc.tar.gz
Description: Simple project to test automoc for various header file locations and names
-- 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
