AUTOMOC ignores Q_OBJECT if preceded by non-whitespace characters

This issue was created automatically from an original Mantis Issue. Further discussion may take place here.

Added area:autogen label

The Q_OBJECT and Q_GADGET macros are expected to start on a new line.

This is unlikely to change but the documentation should be updated.

added area:doc label

Is that a moc requirement?

No, it isn't. I tried the examples given in the Mantis Issue tracker an the (Qt5) moc ran fine. The examples in the moc mapage recommend Q_OBJECT on a single line though.

The limitation in CMake comes from the way the presence of a Q_OBJECT macro is detected, which is by testing the source against this regular expression:

"[\n][ \t]*Q_OBJECT[^a-zA-Z0-9_]"

Hmm. What happens when we falsely detect a file as being moc but isn't?

class foo {
/*
  Q_OBJECT(...)
*/
};

Just a warning that no class was found from moc?

And yes, docs should be clarified.

That's detected as a match and moc prints a warning like:

Note: No relevant classes found. No output generated.

In fact one of the reasons to implement SKIP_AUTOMOC in CMake 3.8 was to allow to ignore files that contain Q_OBJECT in a comment.

!496 (merged) updates the documentation to

If an #include statement like #include "moc_<basename>.cpp" is found, the Q_OBJECT or Q_GADGET macros are expected in an otherwise empty line of the <basename>.h(xx) header file.

Sounds good to me. Could you please add a Fixes #15254 to the commit which fixes it?

The documentation update commit message includes

Closes #15254 (closed)

D'oh. Should have looked to see if it was there; sorry about that.

:)

gitlab used to link to the commit that closes an Issue but I guess that only happens for branches that are already merged now.

It does when merged because that's when the #15254 finally links up (before that, it looks at your fork's issue with that number). It links from anywhere if you reference it as cmake/cmake#15254 (there's also the group-wide cmake#15254 reference).

FWIW I prefer the reference to not have the cmake/cmake prefix if it is from within the CMake project.

Okay, that makes sense.

Sure.

closed via commit d60f1ddc