VS2015 - Suddenly half of sub projects fail to compile
-
I have a large (top level) project with 105 sub projects.
I have two identical development systems.
Both systems are Win10 (from same installer), MSVS2015 (from same installer), qt-opensource-windows-x86-msvc2015-5.8.0.exe (from same installer), qt-vs-tools-msvc2015-2.0.0.vsix (from same installer).The only difference between the two development systems is that the second system has all of the Win 10 updates, were as, the original has seen only a few updates.
Both systems compile the entire code base in Qt Creator.
When I build from Visual Studio on the original system the entire code base compiles.
BUT, when I build from Visual Studio on the new system, about half of the sub-projects fail because they are unable to find the Qt include headers (for example, fatal error C1083: Cannot open include file: 'QWidget': No such file or directory)The projects in both systems are imported identically. That is, the Additional Include Directories include path is identical in both systems and yet one compiles with no problem and the other has problems.
Rearrangement of the include path, (moving the $(QTDIR)/... entries to the front of the include path), in the VS project properties:Additional Include Directories fixes the compile problem. Which indicates that the problem is NOT related to the include path length (see the example below).
But to apply this fix to 40 some projects this is VERY time consuming and not practical to do every time the top level project is re-import (using Qt VS Tools).
I suspect that the problem is related to some change introduced by a Windows update.
Example:
fatal error C1083: Cannot open include file: 'QWidget': No such file or directory (compiling source file .\GeneratedFiles\Debug\moc_transactiontemplateform.cpp)Fix: VS project properties | Additional Include Directories changed
FROM
.\GeneratedFiles$(ConfigurationName);.\GeneratedFiles;.;[ MY PROJECT INCLUDE PATHS];$(QTDIR)\include;$(QTDIR)\include\QtWidgets;$(QTDIR)\include\QtGui;$(QTDIR)\include\QtANGLE;$(QTDIR)\include\QtSql;$(QTDIR)\include\QtCore;GeneratedFiles\debug;$(QTDIR)\mkspecs\win32-msvc2015;%(AdditionalIncludeDirectories)
TO
$(QTDIR)\include;$(QTDIR)\include\QtWidgets;$(QTDIR)\include\QtGui;$(QTDIR)\include\QtANGLE;$(QTDIR)\include\QtSql;$(QTDIR)\include\QtCore;GeneratedFiles\debug;$(QTDIR)\mkspecs\win32-msvc2015;.\GeneratedFiles$(ConfigurationName);.\GeneratedFiles;.;[ MY PROJECT INCLUDE PATHS];%(AdditionalIncludeDirectories)This makes no sense to me...
PLEASE, Does anyone have any ideas about this problem or how to get Qt VS import tool to prepend the Qt include paths instead of appending them? -
@MjrWilson This is kind of weird. You say rearranging the paths fixes the problem, but it shouldn't.
If you have a "cannot open include file" error, then no matter where the include file is in the INCLUDE_DIR path, it should find it. Whether at the beginning or end shouldn't matter except for finding the correct file. But in your case it's not finding an incorrect file, but instead not finding one at all.
The change sounds like it should be coming from the Qt VS Tools conversion and not from any windows/msvc update. So it must be something that was changed in the Qt install or usage of the import tools.
I have not used these tools so I can't comment more on that. I can say that you could consider using cmake which can then generate solution files for you. So there would be no more need for importing Qt project files. Cmake takes a little learning but it's amazing. VS2017 has started introducing native support for cmake too so you don't even need it to generate slns any more, it can just be opened directly to replace your sln files. Just throwing that out there in case using a new build system is an option for you. :)
-
Thank you ambershark for at least taking a stab at this perplexing problem.
Maybe I was not clear about my systems.
Both Build systems are identical with respect to the software.
Both build systems import and generate exactly the same resulting VS projects.
As for the "The change ... coming from the Qt VS Tools conversion and not from any windows/msvc update", I disagree. Both systems are generating the same project output.
Furthermore, once the project has been imported, the Qt tools are no longer in play.
The change that I am making to fix the include problem is MANUALLY changing the setting of the generated VS project's Properties | Additional Include Directories setting (which is exactly the same in both systems). And while I agree with your analysis that "no matter where the include file is in the INCLUDE_DIR path, it should find it", sadly, this is not the case on the new build system, but is in the case of the original system.Furthermore, the fact that I can compile the entire code base from Qt Creator, (which incidentally), uses the VS supplied compiler, tells me that the problem is in VS or something about how the Qt VS Tool behavior is effected due to a Windows update (which is the only difference between the two systems).
I guess I will have to compare the VS and QMake generated makefiles to get to the real issue.
It's been many years since I have had to debug makefiles...BTW, I am familiar with and have used (long ago) CMake. QMake is very similar and, (if I am not mistaken), originally was based on an early version of it. QMake generated the makefiles for Qt Creator which compiles without error. The Qt VS Tool uses QMake to generate the VS solution(s).
If I could figure our how to integrate the VS debugger into the Qt Creator kit, I would be just as happy to ignore VS all together and just use Qt Creator exclusively!
-
for the debugger pls. have a look at https://wiki.qt.io/Qt_Creator_Windows_Debugging
regards
-
@MjrWilson said in VS2015 - Suddenly half of sub projects fail to compile:
Thank you ambershark for at least taking a stab at this perplexing problem.
Maybe I was not clear about my systems.
Both Build systems are identical with respect to the software.
Both build systems import and generate exactly the same resulting VS projects.
As for the "The change ... coming from the Qt VS Tools conversion and not from any windows/msvc update", I disagree. Both systems are generating the same project output.Ah I didn't realize they were generating the same output. From the first post it sounded like there was a difference in order of the includes in the 2nd system's generated files.
Furthermore, once the project has been imported, the Qt tools are no longer in play.
The change that I am making to fix the include problem is MANUALLY changing the setting of the generated VS project's Properties | Additional Include Directories setting (which is exactly the same in both systems).So why do you need to change this manually if the output is exactly the same on both systems? I don't understand this part.
And while I agree with your analysis that "no matter where the include file is in the INCLUDE_DIR path, it should find it", sadly, this is not the case on the new build system, but is in the case of the original system.
That definitely indicates a problem then. If it isn't finding the include and it is in the include path then there is an issue there. I would guess that the file isn't located where it should be. But just a guess with the limited info I have here.
Furthermore, the fact that I can compile the entire code base from Qt Creator, (which incidentally), uses the VS supplied compiler, tells me that the problem is in VS or something about how the Qt VS Tool behavior is effected due to a Windows update (which is the only difference between the two systems).
So it works in Qt Creator but not in visual studio? I just don't see anything done by windows update affecting this. It is possible but not really probable in my experience. More than likely there is some other difference between the 2 systems.
I guess I will have to compare the VS and QMake generated makefiles to get to the real issue.
It's been many years since I have had to debug makefiles...It's not as bad as it sounds. :) You should be able to find differences in a decently quick amount of time. I can't imagine comparing them would take you more than a day even.
BTW, I am familiar with and have used (long ago) CMake. QMake is very similar and, (if I am not mistaken), originally was based on an early version of it. QMake generated the makefiles for Qt Creator which compiles without error. The Qt VS Tool uses QMake to generate the VS solution(s).
CMake is by far my favorite. I used to use qmake before but cmake blows it out of the water in features.
If I could figure our how to integrate the VS debugger into the Qt Creator kit, I would be just as happy to ignore VS all together and just use Qt Creator exclusively!
@aha_1980 answered this one for ya.
-
Blockquote So why do you need to change this manually if the output is exactly the same on both systems? I don't understand this part.
I should have said "The change that I am making ... (which [
isbegin] exactly the same in both systems but only works in the first system)".Blockquote I would guess that the file isn't located where it should be.
Except, the files are there. The files that cannot be found are all of the Qt distribution.
And besides, the location is not in question because the change I make is to the ORDER of the paths, not the PATHS themselves.The problem seems to be a non-recursive search issue.
If you look at my original post, you will see that the change is simply:
[NON-QT PATHS] [QT PATHS] changed to [QT PATHS] [NON-QT PATHS]And anyway, the code compiles in Qt Creator but not in MSVS (unless I make the path change).
-
After much research and a few helpful comments, I bit the bullet and uninstalled and reinstalled both Visual Studio and the Qt Addin and now it all works.
What I did find was that including any Windows SDK other than 10.19393.0 in the Visual Studio install will cause problems at compile time. I am not sure, but it seems that the Qt VS Tools addin is somehow tied to the Windows SDK.
It is hard, at this point, to make any clear statement as to the solution because of all of the installs, uninstalls, reinstalls. And with MS Visual Studio literally taking hours to install, I am not interested in further investigation.
-
@MjrWilson Wow! Typical Visual Studio. One of the many reasons I try to avoid MSVC as a compiler. I've had similar issues at work lately, installing an older win api completely ruined 3 versions of visual studio to the point of reinstalling and having to manually clean the registry. Go Microsoft!
Oh well as a MSFT stock owner at least other people like them even if I don't. ;)
Glad you got it fixed. :)
