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:

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.

Do you have @ECHO somewhere in a project file?

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

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

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:

and it outputs “vcproj”, so I am pretty sure it uses the correct templates.

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

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:

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

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

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.