[CMake] Cannot get automoc to work properly with recommended Qt5 support method

Alan W. Irwin irwin at beluga.phys.uvic.ca
Sun Oct 16 21:40:36 EDT 2016


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
> correctly.
>
> I follow the advice in the above URL and set
>
> set(CMAKE_AUTOMOC ON)
>
> and also set AUTOMOC_MOC_OPTIONS to the following list:
>
> -DPLD_bmpqt;-DPLD_jpgqt;-DPLD_pngqt;-DPLD_ppmqt;-DPLD_tiffqt;-DPLD_svgqt;-DPLD_pdfqt;-DPLD_qtwidget;-DPLD_extqt;-DPLD_memqt
>
> 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
>
> set(CMAKE_INCLUDE_CURRENT_DIR ON)
>
> 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 };
>
> Finally,
>
> "ldd -r bindings/qt_gui/libplplotqt.st"
>
> shows missing symbols that should be defined if the above macros are
> defined.
>
> 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
documentation):

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 mentioned
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?/>

the
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 specific
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

__________________________
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
__________________________


More information about the CMake mailing list