On 2016-10-16 13:43-0700 Alan W. Irwin wrote:

Hi Stephen:

I am addressing you directly (as well as the list) because you have
been so helpful with Qt5 issues in the past.

The PLplot build system (some of whose components depend on Qt5)
currently uses one of the older Qt5 support methods documented at
<http://doc.qt.io/qt-5/cmake-manual.html>.  But that method is complex
and we are currently running into troubles with it where it uses the
plain target_link_libraries command which conflicts with the keyworded
version that we prefer for our build system.  So I have attempted to
update our Qt5 support to the latest target_link_libraries method
documented at the above URL, but automoc appears not to be working

I follow the advice in the above URL and set


and also set AUTOMOC_MOC_OPTIONS to the following list:


This list is the same as I use for MOC_OPTIONS in the old working method, and
these various macro definitions _must_ be defined to avoid dropping large
swaths of our code from the compilation.  Instead of using


I use instead (in the directory where the plplotqt library is built)

include_directories(${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ...)

Furthermore, in that same directory I use

target_link_libraries(plplotqt PRIVATE plplot ${MATH_LIB} Qt5::Svg Qt5::Gui Qt5::PrintSupport)

for the build.  Although that build apparently works with no obvious
issues, there is no sign of any of the above macros in the
VERBOSE=1 output.  Furthermore, I get the following near-empty result
for the generated bindings/qt_gui/plplotqt_automoc.cpp file which
consists just of the following two lines:

/* This file is autogenerated, do not edit*/
enum some_compilers { need_more_than_nothing };


"ldd -r bindings/qt_gui/libplplotqt.st"

shows missing symbols that should be defined if the above macros are

What am I missing?

I have now looked further, and the missing symbols in the library
correspond exactly to classes in an included header (in a different
PLplot source-tree directory, see below) that have a reference to Q_OBJECT.
Furthermore, when I exclude some of those classes by manipulating
AUTOMOC_MOC_OPTIONS, the corresponding missing symbols disappear from
the library so it appears AUTOMOC_MOC_OPTIONS is actually working
despite no visible sign of that in the "make VERBOSE=1 ..." results.

So I am now looking at something else which is referred to in the
following (from CMake 3.6) automoc documentation (where I have
interpolated questions concerning the ambiguities in that

When this property is set ON, CMake will scan the source files at build time 
and invoke moc accordingly.

<QUESTION: do "source files" include all software project headers that are 
in #include statements?/>

If an #include statement like #include "moc_foo.cpp" is found,

<QUESTIONS: found where?  in the source file or header file #included
from that source file?  With regard to the name pattern, is it
assumed the source file is called foo.cpp?/>

Q_OBJECT class declaration is expected in the header, and moc is run
on the header file. A moc_foo.cpp file will be generated from the
source’s header into the CMAKE_CURRENT_BINARY_DIR directory. This
allows the compiler to find the included moc_foo.cpp file regardless
of the location the original source. [....]

If an #include statement like #include "foo.moc" is found,

<QUESTION: found where?  in source file or header file?/>

then a
Q_OBJECT is expected in the current source file and moc is run on the
file itself. Additionally, header files with the same base name (like
foo.h) or _p appended to the base name (like foo_p.h) are parsed for
Q_OBJECT macros, and if found, moc is also executed on those files.
AUTOMOC checks multiple header alternative extensions, such as hpp,
hxx etc when searching for headers.

<QUESTION: does moc follow just ordinary #includes in a source file?  I have a 
example below./>

The resulting moc files, which are
not included as shown above in any of the source files are included in
a generated <targetname>_automoc.cpp file, which is compiled as part
of the target.

I have no such #includes which is probably the entire source of the
issue, but I cannot figure out exactly what to do because of ambiguities
in the above documentation concerning what should be in the header
and what should be in the source file.

To be explicit suppose you have some source code named fooqt.cpp
which contains

#include "barqt.h"

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.

@CMake developers: It would be nice to also have an automoc
documentation fix for those ambiguities since the #include pattern in
the source code must be different than what works for older Qt5
support methods that do not use automoc.


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: 

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:

Reply via email to