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

[Alan W. Irwin]

On 2016-10-16 18:40-0700 Alan W. Irwin wrote:

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

It turned out I could get it to work by specifying (at the end of
fooqt.cpp)

#include "moc_barqt.cpp"

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
out.

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
considerably.

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
__________________________