VS2010 recompiles all moc files every time i build
Sorry if this has been asked before, but I have tried googling on this and searching these forums, but I couldn’t find a solution.
I have quite big project with many static libraries. On windows I build in Visual Studio 2010 and generate the VS files withqmake CONFIG=debug_and_release -tp vc -r
This works pretty well, everything compiles and links OK. However, all files that have a Q_OBJECT macro are MOC’ed and recompiled everytime I build, even if I haven’t touched any files. This means that everytime I start the debugger it rebuilds a lot of files which takes quite a while…
The qmake project files are quite big so I don’t think I’ll post them right away, hopefully some of you have had this problem before and can point me in the right direction :-)
I also had (and have) this problem. An answer on stackoverflow [stackoverflow.com] helped me to find the cause of this: The dependency checker of VS2010 does not find the Qt header files that are included in the generated moc_*.cpp and/or ui_*.cpp
files (because qmake generates relative include paths for the Qt include folders) and thinks it has to regenerate these files to fix this. I never managed to correct this for all files in my projects. I think it may work if your sources and the Qt folder are on different drives.
Thanks for the tip! I tried this approach and DebugView reports the following for each project that is recompiled: Project ‘G:\Projects\Test\src\libs\SngCigi\SngCigi.vcxproj’ is not up to date because 1 build inputs were missing.  up to date is missing: ‘G:\PROJECTS\TEST\SRC\LIBS\SNGCIGI\@ECHO’
All of them report some directory with an @ECHO at the end.
This doesn’t seem right at all?
I tried with Qt installed on the same drive and on a different drive btw, there was no difference in these cases.
No, not in my .pro files, but the .vcxproj file is full of them, so I guess it’s qmake that adds them.
Edit: Another thing, this only happens when I compile in VS. If I compile from the same project files in QtCreator, I don’t get this problem.
Now, if I could only get debugging to work in QtCreator I wouldn’t have to use VS at all, but that’s a completely different story that deserves a separate post :)
Thanks again for input :-)
- QTDIR is set to the correct directory
- QMAKESPEC is set to win32-msvc3010
- I haven’t changed any of the mkspecs files
The echoes are in two different sub-tags under CustomBuild in the .vcxproj:
- <CustomBuild Include="SngGuiOptsCigiIG.h">
- <AdditionalInputs Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">@echo;SngGuiOptsCigiIG.h;%(AdditionalInputs)</AdditionalInputs>
- if errorlevel 1 goto VCEnd
- ... lots more of the same....
- G:\Qt\4.8.1\bin\moc.exe -DUNICODE -DWIN32 -DQT_LARGEFILE_SUPPORT -DUSE_OIS_JOYSTICK -DQT_NO_DEBUG -DHAVE_GPC -DHAVE_TIFF -DHAVE_JPEG -DHAVE_LIBZ -DHAVE_ACTC -DUSE_AGP_MEM -DHAVE_MSFS -DGNG_QT_SUPPORT -DHAVE_COLLADA -DUNICODE -DHAVE_BULLET_DYNAMICS -DHAVE_OPENAL -DWIN32 -D_WINSOCKAPI_ -D_WIN32_WINNT=0x0501 -DNOMINMAX -D_CRT_SECURE_NO_WARNINGS -DFTGL_LIBRARY_STATIC -DHAVE_OPENAL -DSOUND -DBT_USE_DOUBLE_PRECISION -DNO_GL_UI -DQT_THREAD_SUPPORT -DQT_NO_DEBUG -DQT_WEBKIT_LIB -DQT_SCRIPT_LIB -DQT_SQL_LIB -DQT_XML_LIB -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB @$(MACHINE_TYPE)/opt/mocinclude.tmp -D_MSC_VER=1600 -DWIN32 SngGuiOptsCigiIG.h -o win32\opt\moc_SngGuiOptsCigiIG.cpp</Command>
- <Message Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">MOC SngGuiOptsCigiIG.h</Message>
- <Outputs Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">$(MACHINE_TYPE)\nopt\moc_SngGuiOptsCigiIG.cpp;%(Outputs)</Outputs>
I have a very similar problem but I also have a hint for you.
Let’s start with the hint: I also had those @ECHOs in my vcxproj files and investigated, where they come from. For me they only occurred in one of my 180 projects so I looked for obvious differences and found one. The include path of this particular project contains more entries than all others, 42 or 43. So I gave it a try and searched for “40” in Qt files. Surprisingly I found something.
The reason for this @ECHO is a workaround within the qt implementation for Windows XP which has problems when include paths are too long. So they built a workaround in the file $(QTDIR)/mkspecs/features/moc.prf, where they check if there are more than 40 include paths configured and then use a temporary file instead. This does not work correctly and produces the @ECHO.
Solution: Try to set the value from 40 to 100 in the moc.prf file (or even higher) or reduce your include pathes below 40.
And now for my similar problem. My VS 2010 also thinks it has to rebuild moc’ed stuff and I found out why. I just did not find out how to avoid it so maybe you can help me.
The reason for the VS to think so are some entries in the AdditionalInputs in the vcxproj. This looks like this:
ScriptButton.h and UpDownControl.h are files which are included in the (generated) header that belongs to the ui file.
In the ui file it looks like this
Unfortunately those headers are part of a different project. VS generates wrong pathes for these (thinking they are in the local project) and keeps regenerating them because they are never found locally.
Now I looked why I did not get this problem using Qt 4.7, and there the line in the vcxproj looks like this:
As you can see, the headers are not there. So a solution for me could be, not to create those headers there. They are obviously not needed. How can I solve this?
Genious! By increasing this limit, everything works as it should! Thank you so much, this was driving me nuts!
I’m terribly sorry that I can’t be of much help with your problem though :-(
The only thing I can think of would be to keep a copy of the custom widget source in the main project, but that isn’t very nice either.
Do you have the same problem if the custom widget projects are on the same drive as the main project?
Fine that I could help you.
For my problem I meanwhile use a workaround I found at http://connect.microsoft.com/VisualStudio/feedback/details/606628/error-msb6001
But of course I would rather not patch microsoft.commoncpp.targets so any other idea would be appreciated.
And the drive has nothing to do with this.