Disclaimer:
I am no expert on any of this stuff so the conclusions I have drawn
are based on the particular experiments I have done and are probably
limited because of that.
On 2016-10-20 21:17+0200 Tobias Hunger wrote:
Hi!
Am 20.10.2016 21:08 schrieb "Brad King" <brad.k...@kitware.com>:
On 10/20/2016 02:30 PM, Alan W. Irwin wrote:
To be specific here is the way I believe automoc should work. If
#include "moc_<name>.cpp"
is found in a source file under automoc
control, then if moc_<name>.cpp could not be found in any of the
include directories for the target, then search those include
directories (including source-tree equivalents of build-tree include
directories) for <name>.h, run moc on that file and place the result
moc_<name>.cpp in the build directory corresponding to <name.h>.
[snip]
this is a plea to the CMake developers to fix the above deficiency
If you include moc_name.cpp, then you need to run moc on this *source*
file. That is what allows you to have private classes in your source file
that derive from QObject.
That is not the case I am concerned with which is the source file has
no direct reference to the Q_OBJECT macro. Instead it #includes a
header that uses that macro. My experiments (see disclaimer above)
with that case show moc needs to be run directly on the header, and
the resulting generated file needs to be #included in the source file.
The headers should be covered by automoc automatically: Any header
containing a Q_OBJECT macro should be moc-ed. So there should not be any
need to include moc_*.cpp files in source files for any header.
Actually my experiments show the headers using the Q_OBJECT macro are
completely ignored by automoc unless you specifically put
#include moc_<name>.cpp
in the source file, and that works only if <name>.h is in the current
directory. And I want to see that severe current directory limitation
removed as above.
At least that is how I always use this with qmake, but I am hardly an
expert on how moc should work:-)
That lack of expertise goes double for me. :-) See disclaimer above.
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
__________________________
--
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
