Details
-
Bug
-
Resolution: Fixed
-
P2: Important
-
2.5.1
-
None
-
-
3b466a033f53f745cc37db0387fd3614186d2e76
Description
Project structure
\---QtMoc QtClass.h QtClass2.cpp QtMoc.vcxproj
Environment
- Visual Studio 19 - v16.6
- Qt 5.15.0 - msvc2019
Steps to reproduce
In the attached project files, there are two different classes to reproduce this issue - QtClass.h & QtClass2.cpp:
QtClass.h:
#pragma once #include <QObject> class QtClass : public QObject { Q_OBJECT };
QtClass2.cpp:
#include <QObject> class QtClass2 : public QObject { Q_OBJECT }; #include "moc_QtClass2.cpp"
When compiling this code, moc will produce under the QtMoc/Debug/moc/ directory these two files: moc_QtClass.cpp & moc_QtClass2.cpp.
In the generated moc_QtClass.cpp file, it would add an include to the moced file ( #include "../../QtClass.h"), because it is a moced header file:
In the generated moc_QtClass2.cpp file, it would not add the include, because it is a moced CPP file.
By changing the extension of the QtClass2.cpp file to .H and removing the #include at the bottom of the file, it would compile without an issue.
Desired behavior
I'm not entirely sure how the VS extension would handle a scenario like this, but I believe it should compile this example as it used to be. Note that I encountered this issue while migrating some of my projects to use Qt's MsBuild new approach.
This becomes problematic when some classes are using the PIMPL idiom or opaque pointer pattern.
While compiling the QtService project:
https://github.com/qtproject/qt-solutions/tree/master/qtservice
I realized that the MOC in VS doesn't handle the QtServiceStarter & QtServiceControllerHandler as it used to be with fixed VS configurations - before migrating to Qt-MsBuild.
Thank you once again!
Kind regards,
Gilad