VS2010 recompiles all moc files every time i build

tseval

Hi,

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 with

qmake 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 :-)

Cheers

hmuelner

I also had (and have) this problem. An answer on "stackoverflow":http://stackoverflow.com/questions/2762930/vs2010-always-thinks-project-is-out-of-date-but-nothing-has-changed 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.

tseval

Thanks for the tip! I tried this approach and DebugView reports the following for each project that is recompiled:

[5988] Project 'G:\Projects\Test\src\libs\SngCigi\SngCigi.vcxproj' is not up to date because 1 build inputs were missing.
[5988] 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.

hmuelner

Do you have @ECHO somewhere in a project file?

tseval

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 :)

hmuelner

Do you generate your .vcxproj file with qmake -t vcapp (or do you have a TEMPLATE = vcapp) in your .pro file?

tseval

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.

hmuelner

I am almost out of ideas, but you could check:

the context of those @ECHOS in your .vcxproj for hints where they come from
if have you modified files in mkspecs\win32-msvc2010
if are there definitions for QTDIR or QMAKESPEC in your environment

tseval

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>
@

tseval

BTW: I tried removing the echo from the AdditionalInputs tags, since it didn't seem to have any function. However, it made no difference.

drago60000

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?

tseval

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?

drago60000

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.

piroxiljin

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.

tiho_d

drago60000. I had similar problem finding out why VS was constantly rebuilding. I found the answer under the following link in stackoverflow:

http://stackoverflow.com/questions/2762930/vs2010-always-thinks-project-is-out-of-date-but-nothing-has-changed

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.

tiho_d

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.