The last three examples in the docs for qt_wrap_cpp() use an unexpected pattern that initially looks like a bug. Here's the simplest one:

 set(SOURCES myapp.cpp main.cpp)
 qt_wrap_cpp(SOURCES myapp.h)
 qt_add_executable(myapp ${SOURCES})

Here, the first argument to qt_wrap_cpp() is not a target, so it will be treated as the name of an output variable. Normally, when a function supports an output variable to hold a list of produced files, it would discard any previous contents of that variable and just set it to a new value in the caller's scope. But qt_wrap_cpp() doesn't do that, it appends to any existing contents. It is really easy to miss the somewhat ambiguous sentence that says:

The paths of the generated files are added to <VAR>.

One could read that as preserving any original contents of <VAR>, or not preserving them depending on your interpretation. It would be more unambiguous to state explicitly that files are "appended to any existing contents of <VAR>".

That said, I think it is not a good approach to rely on appending. It is unexpected and not how CMake code normally works. I would suggest modifying the examples to not set SOURCES before the call to qt_wrap_cpp(), and instead either append to the result of qt_wrap_cpp(), or even better to just list the rest of the hard-coded files directly in the call to qt_add_executable(). It would also be wise not to use all uppercase for the variable name, because that makes it look like a keyword instead (that's what initially caught my attention to this whole saga). For example:

 qt_wrap_cpp(generatedSources myapp.h)
 qt_add_executable(myapp
    myapp.cpp
    main.cpp
    ${generatedSources}
)