Re: [cmake-developers] Current deficiencies of automoc

[Alan W. Irwin]

On 2016-10-22 03:35+0100 Sascha Cunz wrote:


But automoc must know where to look for. It can only do that if

something tells it where to look - If your header files are in the
same directory as the source files, they’re getting added and scanned
automatically.

If, like in your example, the files are in different directories,

you have to add them to add_executable / add_library in order to let
automoc know that it shall scan them.

That is a good summary of what I have discovered through
experimentation.  However, I view these results for the separate
header file directory as an unexpected constraint of automoc at best.
Compilers know exactly where the header files are through
include_directories or the equivalent target PROPERTY so why can't
automoc find those same header files using similar logic?

Of course, I am in the odd position (as I explained before) of not
being able to help out with implementing such logic so if it turns
out nobody wants to clean up this issue at the moment, I will put
it on the bugtracker for future reference.

[...]


However, I see that the take away from the thread should probably be

that the wording in the documentation could be improved. To be fair,
it is in general very hard for someone who knows a tool and it’s
complete history to write documentation that someone who doesn’t have
that prior knowledge is able to understand. So, improving things here
usually relies on input like yours to figure out what actually has to
be improved.

I agree.  I have already suggested some possible changes to the
documentation on the initial thread on the CMake mailing list and this
additional thread here on the CMake developer list.  But if nobody is
inspired to take immediate action on fixing the problem summarized
above (which would largely make the current documentation correct), I will write
up these documentation issues for the current automoc behaviour for
the bugtracker as well.

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

Re: [cmake-developers] Current deficiencies of automoc

[Sascha Cunz]

Hi Alan,

> On 22 Oct 2016, at 02:01, Alan W. Irwin  wrote:

> …

> I don't agree with your above conclusion.  The above remarks immediately 
> refer to
> header files and imply automoc scans them

Which it does :)

> to find the ones that contain the Q_OBJECT macro and

and/or Q_GADGET.

> certainly does not imply the user must list the files to be scanned directly

Right. And it’s not required most of the time.
But automoc must know where to look for. It can only do that if something tells 
it where to look - If your header files are in the same directory as the source 
files, they’re getting added and scanned automatically (Not related to automoc, 
actually). See the minimum example below.

If, like in your example, the files are in different directories, you have to 
add them to add_executable / add_library in order to let automoc know that it 
shall scan them.

> as fullpaths in the add_executable (or add_library) command.

The full path requirement here is a false perception. It will certainly do no 
harm to be explicit with the parameters to add_executable/add_library, but the 
default is to search relative to ${CMAKE_CURRENT_SOURCE_DIR}.

And as mentioned by others in the thread, it’s a good idea to explicitly list 
your header files. As this will improve how certain IDEs show your project.

The above _is_ actually the default behaviour that suites 95% of the cases 
where moc needs to be run. For the other cases, where Q_OBJECT / Q_GADGET is 
used inside a .cpp file, there is the option to #include a file following the 
pattern “moc_%s.cpp” where %s is the name of the containing C++ source file 
without extension. 

> And the last sentence implies that if the so-called #include method is not 
> used, then
> automoc will figure everything out for itself, i.e., the fullpath method 
> allowing the
> user to specify which headers are scanned by moc is not documented here at 
> all.

From cmake-qt[7]:

The AUTOMOC target property controls whether cmake(1)
inspects the C++ files in the target
to determine if they require moc to be run.

I clearly states that it will scan the files added to the target.

However, I see that the take away from the thread should probably be that the 
wording in the documentation could be improved. To be fair, it is in general 
very hard for someone who knows a tool and it’s complete history to write 
documentation that someone who doesn’t have that prior knowledge is able to 
understand. So, improving things here usually relies on input like yours to 
figure out what actually has to be improved.
I could imagine that in this case, the term “C++ files” didn’t trigger an 
association to header files.

Cheers,
Sascha

P.S.: Since both Qt4 and Qt5 integrations of Qt nowadays use generator 
expressions, in my experience it’s close to impossible to accurately mimic 
automoc behaviour inside CMakeLists.txt. This is though required in one 
specific scenario, but I don’t think this can be fixed unless automoc would be 
rewritten from scratch (If target T has a custom rule that creates a header 
file, which turns out to be run through moc - automoc, which is a separate 
target that T depends on, can impossibly scan the file that [through 
target-dependency] will be generated _after_ the automoc target is built).

Minimal working example:

$ tail -n50 CMakeLists.txt t.cpp t.hpp
==> CMakeLists.txt <==
cmake_minimum_required(VERSION 3.6)
project(X)
set(CMAKE_AUTOMOC TRUE)
find_package(Qt5Core)
add_executable(a t.cpp)
target_link_libraries(a Qt5::Core)

==> t.cpp <==
#include "t.hpp"
int main(int,char**)
{ X x; return 0; }

==> t.hpp <==
#include 
struct X: public QObject{
X() = default;
Q_OBJECT
};



-- 

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

Re: [cmake-developers] Current deficiencies of automoc

[Alan W. Irwin]

On 2016-10-21 23:54+0200 el.bar...@gmx.de wrote:




1. The automoc documentation at
 only
documents the #include method (which doesn't work for the current test
case nor for PLplot), and the above working fullpath method is not
documented at all there. 


At least in cmake-qt(7) [1] this is documented:

If a |Q_OBJECT| or |Q_GADGET| macro is found in a header file, |moc| will be 
run on the file. The result will be put into a file named according to 
|moc_.cpp|. If the macro is found in a C++ implementation file, the 
moc output will be put into a file named according to |.moc|, 
following the Qt conventions. The |moc file| may be included by the user in 
the C++ implementation file with a preprocessor |#include|. If it is not so 
included, it will be added to a separate file which is compiled into the 
target.


Hi Marc:

I have put my response to your comment back on the list where I think it
belongs.

I don't agree with your above conclusion.  The above remarks immediately refer 
to
header files and imply automoc scans them to find the ones that contain
the Q_OBJECT macro and certainly does not imply the user must list
the files to be scanned directly as fullpaths in the add_executable
(or add_library) command.  And the last sentence implies that
if the so-called #include method is not used, then automoc will figure
everything out for itself, i.e., the fullpath method allowing the
user to specify which headers are scanned by moc is not documented
here at all.

If the first sentence in the above paragraph had referred to header
files appearing in the list of source files for add_executable or
add_library and/or if the last sentence in the above paragraph had
been replaced by

"If it is not so included, the user must put the fullpaths of the
headers that need moc processing in the source list for add_executable
or add_library." then I would agree with your conclusion, but that
type of specific documentation of the fullpath method is just not
currently in the cmake-qt documentation.

By the way, I have been able to show that the "leaving it completely
to automoc" method documented above does not work with the second
(fixed) version of my simple example, and I urge you to try that
experiment also by making the following additional change (from
"fullpath" to "leave it to automoc")

-  add_executable(helloworld main.cpp 
${CMAKE_SOURCE_DIR}/include/test_q_object.h)
+  add_executable(helloworld main.cpp)

For this case nm shows everything in test_q_object.h is completely ignored 
by automoc despite the '#include "test_q_object.h"' in main.cpp.


N.B. the above documentation is likely correct and the "leave it to
automoc" method should work but it doesn't for this simple example, and that is 
likely
due to the same bug that keeps the "#include" method from working for
this simple example of an include file in a separate directory.

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

Re: [cmake-developers] Current deficiencies of automoc

[Nagger]

Am 21.10.2016 um 13:39 schrieb Alan W. Irwin:

On 2016-10-21 09:42+0200 Sebastian Holtermann wrote:

headers-to-moc to the sources list.
- add_executable(helloworld main.cpp)
+ add_executable(helloworld main.cpp
+${CMAKE_SOURCE_DIR}/include/test_q_object.h)

The #include "moc_test_q_object.cpp" in main.cpp can be removed then.


1. The automoc documentation at
 only
documents the #include method (which doesn't work for the current test
case nor for PLplot), and the above working fullpath method is not
documented at all there.


At least in cmake-qt(7) [1] this is documented:

If a |Q_OBJECT| or |Q_GADGET| macro is found in a header file, |moc| 
will be run on the file. The result will be put into a file named 
according to |moc_.cpp|. If the macro is found in a C++ 
implementation file, the moc output will be put into a file named 
according to |.moc|, following the Qt conventions. The |moc 
file| may be included by the user in the C++ implementation file with a 
preprocessor |#include|. If it is not so included, it will be added to a 
separate file which is compiled into the target.



Marc


[1] https://cmake.org/cmake/help/v3.6/manual/cmake-qt.7.html#automoc


-- 

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

Re: [cmake-developers] [PATCH] Help: Fix cmake-server typo and message type consistency

[Brad King]

On 10/21/2016 10:30 AM, Tobias Hunger wrote:
> Yes, this change is correct. I stumbled over this myself this afternoon.

Thanks.  I've submitted a MR with the prose updated too here:

 https://gitlab.kitware.com/cmake/cmake/merge_requests/191

-Brad

-- 

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

Re: [cmake-developers] [PATCH] Help: Fix cmake-server typo and message type consistency

[Brad King]

On 10/21/2016 09:51 AM, Sylvain Joubert wrote:
> Please find attached a patch that corrects a typo and a inconsistency
> in a code snippet.

Thanks!

BTW, since you last contributed we've switched from using the mailing
list for patches to using GitLab merge requests:

  https://gitlab.kitware.com/cmake/cmake

Please see the updated CONTRIBUTING.rst.

> -This requist will generate build system files in the build directory and
> +This request will generate build system files in the build directory and

Good catch.

> -  {"type":"project"}
> +  {"type":"codemodel"}
...
> -"inReplyTo":"project",
> +"inReplyTo":"codemodel",

Tobias, please confirm that this change is correct.

It looks like `"project"` is used in the prose shortly after those hunks.
Should those instances be changed too?

Thanks,
-Brad

-- 

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

[cmake-developers] [PATCH] Help: Fix cmake-server typo and message type consistency

[Sylvain Joubert]

Hello,

Please find attached a patch that corrects a typo and a inconsistency in a
code snippet.
The patch is based on the 'release' branch.

Regards,
Sylvain
From c861c3341a59ca635f98e6f56caee7104f16dc32 Mon Sep 17 00:00:00 2001
From: Sylvain Joubert 
Date: Fri, 21 Oct 2016 15:46:12 +0200
Subject: [PATCH] Help: Fix cmake-server typo and message type consistency

---
 Help/manual/cmake-server.7.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Help/manual/cmake-server.7.rst b/Help/manual/cmake-server.7.rst
index afd4e2b..a3a4237 100644
--- a/Help/manual/cmake-server.7.rst
+++ b/Help/manual/cmake-server.7.rst
@@ -403,7 +403,7 @@ CMake will reply like this (after reporting progress for some time)::
 Type "compute"
 ^^
 
-This requist will generate build system files in the build directory and
+This request will generate build system files in the build directory and
 is only available after a project was successfully "configure"d.
 
 Example::
@@ -520,7 +520,7 @@ sourceDirectory of the target.
 Example::
 
   [== CMake Server ==[
-  {"type":"project"}
+  {"type":"codemodel"}
   ]== CMake Server ==]
 
 CMake will reply::
@@ -529,7 +529,7 @@ CMake will reply::
   {
 "cookie":"",
 "type":"reply",
-"inReplyTo":"project",
+"inReplyTo":"codemodel",
 
 "projects":
 [
-- 
2.9.3

-- 

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

Re: [cmake-developers] Current deficiencies of automoc

[Alan W. Irwin]

On 2016-10-21 09:42+0200 Sebastian Holtermann wrote:

[...]

Hi!

I tried your example.
It isn't complete, test_q_object.h needs an
   #include 
and a constructor/destructor definition, e.g.:
   MyClass(QObject *parent = 0) {;}
   ~MyClass(){;}


Hi Sebastian:

Thanks for that fix which indeed solves the linking issue.



With regards to automoc the
   #include "moc_test_q_object.cpp"
in the end should not be neccessary since
   #include "test_q_object.h"
already references to the header.
The problem is that this reference is not a direct path from the
source file but relies on include_directories.
CMake does not seem to populate automoc's scan list with files
from include_directories.
I tried to figure out why but this is quite complex.


I hope you are able to fix this along the lines I have mentioned
(which includes putting all generated results in the build tree
corresponding to the header) since using #include
"moc_test_q_object.cpp" in main.cpp is currently the only documented
way to use automoc (see, e.g.,
).




A quick fix for the example would be to explicitly add the
headers-to-moc to the sources list.
- add_executable(helloworld main.cpp)
+ add_executable(helloworld main.cpp
+   ${CMAKE_SOURCE_DIR}/include/test_q_object.h)

The #include "moc_test_q_object.cpp" in main.cpp can be removed then.


That idea (specifying the fullpath of the original header as part of the source 
code)
does indeed make automoc work properly.  "ldd -r helloworld" shows
no linking issues, I can run the executable without issues,
and "nm --defined-only --demangle helloworld |less" shows lots
of references to MyClass.  I attach a revised tarball
example with the test_q_object.h fix and this
change.

However, there are still two problems with this method which
I will call the fullpath method to distinguish it from the documented
#include method.

1. The automoc documentation at
 only
documents the #include method (which doesn't work for the current test
case nor for PLplot), and the above working fullpath method is not
documented at all there.

2. With that fullpath method, The automoc-generated
helloworld_automoc.cpp and moc_test_q_object.cpp are located in
${CMAKE_CURRENT_BINARY_DIR} (the build directory where the helloworld
executable is located), and that is not ideal.  For example, I have no
idea how the compile process found that directory to include those
files since that directory is specifically not mentioned in
include_directories for this project.  It also means that for
executables and libraries in a variety of directories that include
${CMAKE_SOURCE_DIR}/include/test_q_object.h in their source list will
be generating duplicate moc_test_q_object.cpp in a variety of
different directories.

Thus, it seems to me the more logical location for these two
automoc-generated files would be ${CMAKE_BINARY_DIR}/include. Note
that ${CMAKE_BINARY_DIR}/include/helloworld_automoc.cpp is unique
(because the target name helloworld must be unique), and
${CMAKE_BINARY_DIR}/include/moc_test_q_object.cpp is also unique
because it corresponds to the unique filename
${CMAKE_SOURCE_DIR}/include/test_q_object.h.  So this means there is
no chance of nameclashes with this location (although to be fair that
is also true of the current location for these two generated files).
This suggested location is also the one I suggest for the #include
method, and that consistency of location between the two methods
(and also the qt5_wrap_cpp method) is important.

Of course, if ${CMAKE_SOURCE_DIR}/include/test_q_object.h appears in
source lists for lots of different executables and libraries, automoc
has to test whether ${CMAKE_BINARY_DIR}/include/moc_test_q_object.cpp
has already been generated so that generation is only done once.  I
presume such a check would be easy to implement if automoc doesn't do
that already.

In sum, I hope you are willing to fix the currently documented automoc
"#include" method so it puts all generated results in the build tree
corresponding to the header, update the automoc documentation so you
also mention the "fullpath" alternative, and also similarly fix that
method so the location of the two generated files is in the build
directory corresponding to the header rather than the build directory
corresponding to the source file.

My apologies for making suggestions for improvement without being able
to help you with the implementation (except testing of results), but
my C++ skills and CMake developer skills are just not up to it (as you
could probably tell from the required test_q_object.h fix you had to
suggest.)

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 

Re: [cmake-developers] Current deficiencies of automoc

[Jean-Michaël Celerier]

On Fri, Oct 21, 2016 at 10:10 AM, Sebastian Holtermann 
wrote:

>
> A quick fix for the example would be to explicitly add the
> headers-to-moc to the sources list.


This has the nice side-effect of making your project much easier to use in
IDEs.
-- 

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

Re: [cmake-developers] Current deficiencies of automoc

[Sebastian Holtermann]

Am 21.10.2016 um 01:29 schrieb Alan W. Irwin:

On 2016-10-20 15:08-0400 Brad King wrote:


Please construct a minimal/complete example source tree/tarball
that demonstrate the layout you'd like to have work.  That will
be helpful in constructing such a bug report.


OK. I have attached the requested minimal example to serve as the
basis for further discussion.  The files in the tarball are

test_qt5/
test_qt5/include/
test_qt5/include/test_q_object.h
test_qt5/main.cpp
test_qt5/CMakeLists.txt

include/test_q_object.h is a header that contains a minimal use of
Q_OBJECT.  (Likely too minimal so I will need help with that see below.)
main.cpp is a "hello-world" example that #includes that header.  It also
#includes
the moc-generated moc_test_q_object.cpp.

The USE_AUTOMOC option for this test project defaults to OFF.  In that
default case this test project is set up so that the qt5_wrap_cpp is
called instead of using automoc, and the
result is the compilation works fine (all headers and files generated
by moc are found with no issues) but there is a link error

CMakeFiles/helloworld.dir/main.cpp.o:(.data.rel.ro._ZTV7MyClass[_ZTV7MyClass]+0x28):

undefined reference to MyClass::~MyClass()'

which likely has to do with include/test_q_object.h being too minimal.
I would appreciate help with that issue to complete this example, but
that is a side issue and the principal result is the compile (as
opposed to the link) was a success with the default -DUSE_AUTOMOC=OFF.

However, if you try -DUSE_AUTOMOC=ON with this project the compile
step (before it even gets to the link step) fails as follows:

Automatic moc for target helloworld
/home/software/cmake/install-3.5.2/bin/cmake -E cmake_autogen
/home/software/plplot/HEAD/test_qt5/build_dir/CMakeFiles/helloworld_automoc.dir/
""
AUTOGEN: Checking /home/software/plplot/HEAD/test_qt5/main.cpp
AUTOGEN: error: /home/software/plplot/HEAD/test_qt5/main.cpp The file
includes the moc file "moc_test_q_object.cpp", but could not find header
"test_q_object{.h,.hh,.h++,.hm,.hpp,.hxx,.in,.txx}" in
/home/software/plplot/HEAD/test_qt5/

I hope a simple solution to this deficiency of the current automoc can
be found using the following ideas (copied from my previous post to
keep this self-contained).

If

#include "moc_.cpp"

is found in a source file under automoc
control, then if moc_.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 .h, run moc on that file and place the result
moc_.cpp in the build directory corresponding to .

So the result is moc would be run just once on the correct header file
with the moc_.cpp result stored in one logical location no
matter how many different source files in different directories have
code with the above #include.

Alan
__
Alan W. Irwin


Hi!

I tried your example.
It isn't complete, test_q_object.h needs an
#include 
and a constructor/destructor definition, e.g.:
MyClass(QObject *parent = 0) {;}
~MyClass(){;}

With regards to automoc the
#include "moc_test_q_object.cpp"
in the end should not be neccessary since
#include "test_q_object.h"
already references to the header.
The problem is that this reference is not a direct path from the
source file but relies on include_directories.
CMake does not seem to populate automoc's scan list with files
from include_directories.
I tried to figure out why but this is quite complex.

A quick fix for the example would be to explicitly add the
headers-to-moc to the sources list.
- add_executable(helloworld main.cpp)
+ add_executable(helloworld main.cpp
+   ${CMAKE_SOURCE_DIR}/include/test_q_object.h)

The #include "moc_test_q_object.cpp" in main.cpp can be removed then.

-Sebastian










--

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