VS2010 recompiles all moc files every time i build
-
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 :)
-
I use the option "-tp vc", but that should use the correct template.
To make sure, I tried to output the TEMPLATE variable from inside the .pro file like this:
@message (Template is:)
message ($$TEMPLATE)
@and it outputs "vcproj", so I am pretty sure it uses the correct templates.
-
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>
<Command Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">@echo -IG:\Qt\4.8.1\include/QtCore> $(MACHINE_TYPE)/opt/mocinclude.tmp if errorlevel 1 goto VCEnd
... lots more of the same....
VCEnd 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>
p</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>
</CustomBuild>
@ -
Hi, there
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:
<AdditionalInputs Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">C:\Software\Qt\4.8.0\bin\uic.exe;ScriptButton.h;UpDownControl.h;UserManagement\AssignUserRolesWidget.ui;%(AdditionalInputs)</AdditionalInputs>
ScriptButton.h and UpDownControl.h are files which are included in the (generated) header that belongs to the ui file.
#include "ScriptButton.h"
#include "UpDownControl.h"
In the ui file it looks like this<customwidget>
<class>CActionButton</class>
<extends>QPushButton</extends>
<header>Buttons/ActionButton.h</header>
</customwidget>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:
<AdditionalInputs Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">$(QTDIR)\bin\uic.exe;UserManagement\AssignUserRolesWidget.ui;%(AdditionalInputs)</AdditionalInputs>
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.
-
I had a similar problem.
It was small project with precompiled headers.
I had to disable precompiled headers to prevent recompilation of the Q_OBJECTed classes. -
drago60000. I had similar problem finding out why VS was constantly rebuilding. I found the answer under the following link in stackoverflow:
I will post the answer here too for completeness and in case something gets lost on the web:
To find the missing file(s), use info from the article Enable C++ project system logging to enable debug logging in Visual Studio and let it just tell you what's causing the rebuild:
1# .Open the devenv.exe.config file (found in %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\ or in %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE)
2.#
Add the following after the </configSections> line:
@<system.diagnostics>
<switches>
<add name="CPS" value="4" />
</switches>
</system.diagnostics>@3.# Restart Visual Studio
4.# Open up DbgView and make sure it's capturing debug output
5.# Try to debug (hit F5 in Visual Studio)
6.#
Search the debug log for any lines of the form:devenv.exe Information: 0 : Project 'Bla\Bla\Dummy.vcxproj' not up to date because build input 'Bla\Bla\SomeFile.h' is missing.
(I just hit Ctrl+F and searched for not up to date) These will be the references causing the project to be perpetually "out of date".
To correct this, either remove any references to the missing files from your project, or update the references to indicate their actual locations.
-
There is another "trick" to tell MOC to fix the long includes. Some time ago I found that Qt has a back door switch that I am using currently in my projects with long include paths. Add to your project file the following line:
@mocinclude.CONFIG *= fix_target@
The above fixes the path, but does not fix the ECHO inside the VS2010 project files described above, so a combination of both is recommended.
Also many thanks to drago60000 for his finding about modifying the moc.prf file.