[Development] RFC: CMake's automoc option to warn about missing moc includes; or not have mocs_compilation.cpp

[Friedrich W. H. Kossebau]

Hi Alex,

thanks for your reply.

Am Freitag, 14. Juli 2023, 09:44:46 CEST schrieb Alexandru Croitor:
> I think adding the 2 proposed features (showing include warnings and
> disabling mocs_compilation) make sense. Having global variables control the
> per target property values also makes sense.

Good, so looks those ideas are not that off.

> Not sure how useful per-source-file properties would be, and it would also
> complicate the implementation.

Would not have a real world example yet myself, after having treated 3 digit 
number of repos with some total 4 digits numbers of includes added the last 
weeks (maniac mode: on), big jay for scripts #)
Any few strange setups (e.g. with bigger header used from different targets 
but only for subsets of the declarations in the header) were resolved into 
"more sane" ones. But it made me think some people might still fancy such 
strange setups for whatever reasons, so for now have a question mark there... 
:)

> I would not change the defaults, because it will either break existing
> projects or start showing a lot of warnings.

Agreed. And if in the end people think that for better code culture e.g. at 
least warning about falling to automatic separate compilation should be a 
default, that could be solved via CMake policies which would only change 
defaults when triggered via the usual policy change system.

> Whether we want to encourage all cmake project developers to manually
> include their mocs in the more distant future is up for discussion. It
> probably makes sense for certain kinds of projects, but not others.

Yes, having for some years removed many moc includes in old code myself, for 
some "cleaner" style, I think I can see both sides. Myself even kept separate 
headers for QTest tests instead of declaring the test QObject class in the 
same source file, to avoid that "dirty" test.moc include ;)

But having now reflected about it and seen some numbers, I changed my mind 
given the number of advantages:
* more compiler sanity check (unused private field at least for now)
* tiny bit more optimized binary code
* faster incremental builds (+ faster w/ more forward declarations possible)
* faster full builds (+ faster w/ more forward declarations possible)

Working with a mobile device as these days lots of developers seem to do, 
there cutting some 2-20 % (as by some samples taken) of full build time and 
thus energy consumption, similar with incremental builds, that is worth some 
extra code lines IMHO to stay longer on the balcony/in the garden, only be 
mosquito-constrained :)

We all dislike the current imperfection with moc and the generated code files. 
And all the automagic is nice to reduce the amount of resulting extra work. 
Just. for any source files that are moc'ed, one has to know about the details 
and care about adding the include to source the generated file. So doing the 
same for headers as one does for source files should not be such a tragedy.

I guess selling Qt to newbies & managers is easier when hiding moc files under 
the automoc carpet in demo code though ;) But once you run into "undefined 
reference to vtable" errors etc. and wonder what is going on, you have a 
harder time to understand things compared to when knowing in advance that 
there is generated code also for each Qt-macro'ed classes, that also needs 
building.
If one can master C++ as much as needed, that part is easy to grasp, no?
But if having to learn the hard way, some at least feel cheated as well take 
longer to grasp things.

So for the question whether one wants to encourage all cmake project 
developers, my personal vote would be: yes :) At least for anything that is 
not throw-away code, but is to live on a bit.

But others might have other opinions on which kinds of projects it makes sense 
for certain reasons, so please share those :)

> And
> lacking automated tooling to do the work, and instead force the manual work
> on each developer, is not a very enticing proposition.

Yes  I would hope though that with more people getting aware for the 
motivation to do explicit includes that tooling might also catch up here.

After all there is already first work in that direction, see e.g. the git hook 
at https://github.com/KDAB/KDToolBox/tree/master/qt/includemocs
which I suppose was done once their author (not affiliated to me) found out 
about things, as also documented in 
https://www.youtube.com/watch?v=Cx_m-qVnEjo

> As to the question on existing plans to work on something like the proposed
> features, to my knowledge, currently there aren't any.

Okay, so would for now keep the proposed as draft to enhance then, given the 
current encouraging feedback. Thanks again.

Curious to hear more people's opinions on this, of course.

Cheers
Friedrich