[Resending to the entire list this time] On Thu, May 28, 2020 at 3:12 PM Thiago Macieira <[email protected]> wrote:
> On Thursday, 28 May 2020 10:19:58 PDT Adam Light wrote: > > I'm including generating moc files in "build time". I'm not saying that > > compiling the .cpp files will take significantly longer, but if a .cpp > file > > has a #include "myclass.moc" type statement, that .cpp file has to be > > processed by moc > > You're talking about when myclass.cpp has a Q_OBJECT. That's the only > reason > when moc needs to parse that .cpp. > > But you also don't have a choice. You have to #include the .moc output. > Yes, that's right. > We're talking about #include "moc_myclass.cpp", which is when "myclass.h" > has > a Q_OBJECT. You don't have to have that #include. But if you do, then it's > one > fewer .cpp file that needs to be compiled. It generates better code and > enables more warnings. > > The only drawback is that the compilation needs to wait for moc to finish. > If > you have a cluster, it means the cluster can't be used until moc has > finished, > for that file. But that's only for the first file. > Right. I got confused about the earlier mention of ".moc", even though it clearly would not make sense for every class that uses Q_OBJECT to be declared in a .cpp file. I will note, however, that #including the moc output from the .cpp file (the "moc_myclass.cpp" form) is not compatible with my mocinclude trick posted at https://bugreports.qt.io/browse/QTBUG-81348. And we are not using a cluster or anything particularly fancy, just a regular (self-built) desktop machine with a 16 core/32 thread AMD Threadripper processor and otherwise high end consumer components. Adam
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
