On 2016-10-21 09:42+0200 Sebastian Holtermann wrote: [...]
Hi!I tried your example. It isn't complete, test_q_object.h needs an #include <QObject> and a constructor/destructor definition, e.g.: MyClass(QObject *parent = 0) {;} ~MyClass(){;}
Hi Sebastian: Thanks for that fix which indeed solves the linking issue.
With regards to automoc the #include "moc_test_q_object.cpp" in the end should not be neccessary since #include "test_q_object.h" already references to the header. The problem is that this reference is not a direct path from the source file but relies on include_directories. CMake does not seem to populate automoc's scan list with files from include_directories. I tried to figure out why but this is quite complex.
I hope you are able to fix this along the lines I have mentioned (which includes putting all generated results in the build tree corresponding to the header) since using #include "moc_test_q_object.cpp" in main.cpp is currently the only documented way to use automoc (see, e.g., <https://cmake.org/cmake/help/v3.6/prop_tgt/AUTOMOC.html>).
A quick fix for the example would be to explicitly add the
headers-to-moc to the sources list.
- add_executable(helloworld main.cpp)
+ add_executable(helloworld main.cpp
+ ${CMAKE_SOURCE_DIR}/include/test_q_object.h)
The #include "moc_test_q_object.cpp" in main.cpp can be removed then.
That idea (specifying the fullpath of the original header as part of the source code) does indeed make automoc work properly. "ldd -r helloworld" shows no linking issues, I can run the executable without issues, and "nm --defined-only --demangle helloworld |less" shows lots of references to MyClass. I attach a revised tarball example with the test_q_object.h fix and this change. However, there are still two problems with this method which I will call the fullpath method to distinguish it from the documented #include method. 1. The automoc documentation at <https://cmake.org/cmake/help/v3.6/prop_tgt/AUTOMOC.html> only documents the #include method (which doesn't work for the current test case nor for PLplot), and the above working fullpath method is not documented at all there. 2. With that fullpath method, The automoc-generated helloworld_automoc.cpp and moc_test_q_object.cpp are located in ${CMAKE_CURRENT_BINARY_DIR} (the build directory where the helloworld executable is located), and that is not ideal. For example, I have no idea how the compile process found that directory to include those files since that directory is specifically not mentioned in include_directories for this project. It also means that for executables and libraries in a variety of directories that include ${CMAKE_SOURCE_DIR}/include/test_q_object.h in their source list will be generating duplicate moc_test_q_object.cpp in a variety of different directories. Thus, it seems to me the more logical location for these two automoc-generated files would be ${CMAKE_BINARY_DIR}/include. Note that ${CMAKE_BINARY_DIR}/include/helloworld_automoc.cpp is unique (because the target name helloworld must be unique), and ${CMAKE_BINARY_DIR}/include/moc_test_q_object.cpp is also unique because it corresponds to the unique filename ${CMAKE_SOURCE_DIR}/include/test_q_object.h. So this means there is no chance of nameclashes with this location (although to be fair that is also true of the current location for these two generated files). This suggested location is also the one I suggest for the #include method, and that consistency of location between the two methods (and also the qt5_wrap_cpp method) is important. Of course, if ${CMAKE_SOURCE_DIR}/include/test_q_object.h appears in source lists for lots of different executables and libraries, automoc has to test whether ${CMAKE_BINARY_DIR}/include/moc_test_q_object.cpp has already been generated so that generation is only done once. I presume such a check would be easy to implement if automoc doesn't do that already. In sum, I hope you are willing to fix the currently documented automoc "#include" method so it puts all generated results in the build tree corresponding to the header, update the automoc documentation so you also mention the "fullpath" alternative, and also similarly fix that method so the location of the two generated files is in the build directory corresponding to the header rather than the build directory corresponding to the source file. My apologies for making suggestions for improvement without being able to help you with the implementation (except testing of results), but my C++ skills and CMake developer skills are just not up to it (as you could probably tell from the required test_q_object.h fix you had to suggest.) 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 __________________________
version2_testqt5.tar.gz
Description: tarball containing version 2 of simple test project for automoc
-- 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
