On 2016-10-16 18:40-0700 Alan W. Irwin wrote:
To be explicit suppose you have some source code named fooqt.cpp
which declares some classes for the software package that refer to Q_OBJECT
and some classes that do not refer to Q_OBJECT.
What is the #include recipe to get automoc to work for this specific case?
In the next few hours I plan to try some #include variations allowed
by the ambiguities of the above documentation so I may eventually
answer my own question by these experiments. But it would be nice to
get a definitive answer.
It turned out I could get it to work by specifying (at the end of
However, it only looked in the directory where fooqt.cpp was located
for barqt.h, and a special twist for the PLplot case was barqt.h was
located in a separate directory so it could not find it. I then tried
adding the appropriate -I directive to CMAKE_AUTOMOC_MOC_OPTIONS.
Note, this time I used the correct name of that variable (and not
AUTOMOC_MOC_OPTIONS like I used before.) So VERBOSE=1 output showed
moc being run properly with all the macros defined as well as that -I
directive. However, it was run on the barqt.h in the same directory
where fooqt.cpp was located and failed because barqt.h only existed in
a separate directory. I worked around this by temporarily deploying a
symlink, but that method won't work on Windows, and it may generate
name conflicts for the case of our other Qt5-related components
built in separate directories which also use this same header.
So is there a proper method to work with headers that that are used by
multiple software components in different directories? If not, I
would consider that to be a big deficiency of the latest Qt5 support
method since this is not a problem for the old Qt5 support method.
By the way, even with the symlink workaround that allows automoc to
generate a moc command that actually works, the moc_barqt.cpp results
that are #included in fooqt.cpp generate two compiler errors when
fooqt.cpp is built. So I will try to use my rudimentary C++ skills to
debug that issue going forward, and I may ask more questions
concerning those build issues if I cannot figure these build issues
A general comment is this whole project to update to the latest Qt5
support method has been painful, and it is not done yet even for just
the one component I am testing it on so far. And this pain is despite
the fact that the PLplot build worked smoothly (aside from the
plain/keyword target_link_libraries conflict that motivated this
update) before using the old Qt5 support method. Less ambiguous
documentation of automoc that included how to deal with include files
that are #included by separate software components in different
directories would ease the pain of using the latest Qt5 support method
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).
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
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
Follow this link to subscribe/unsubscribe: