We have a fairly large solution (>200 projects) and recently switched to VS2019. We are using Qt 5.14 with Qt Visual Studio Tools 2.7.1.18 and QtMsBuild. After we started using VS 2019 we get the following warning multiple times when we build the solution:
“…AppDataLocalQtMsBuildqt_globals.targets(131,5): warning : Qt::BuildLock[{E42AFBC7-0C5E-441F-B1DB-AE4C9E75F86E}]: Waiting…”
The GUID is the GUID from one of the projects in the solution. Sometimes the build process even hangs up on the “Waiting…” but in most cases the warning does not seem to have an obvious effect other than that it is displayed.
My question is: Where does this warning come from? Why does it show? And how can we get rid of it?
I recently had a problem pop up seemingly out of nowhere. It’s described in this issue: Visual C++ Builds Failing due to Log File Access Collision
Based on my investigation, Visual Studio appears to be redundantly building project dependencies instead of just referencing them, and when multiple projects with the same dependency build simultaneously, they will both hit a log file (or some other file) simultaneously, causing one to fail due to access restriction.
It seems that the QtMsBuild developers solved this by adding a CriticalSection task to the QtPrepare target preventing concurrent access. The downside is that this gets reported as a warning.
When building a c++ application with Qt from command line, you could encounter the following error, we were using the version 3.0.1 of Qt-VS-plugin addin:
C:Users<username>AppDataLocalQtMsBuildqt_globals.targets(133,5): error : Qt::BuildLock[{E40DFD64-87D0-3186-9957-FD9974139787}]: Timeout; wait aborted [….vcxproj]
This is because the same project is apparently being build at the same time due to multithreading in the build process. By default, There is a 10s timeout defined in C:Users<username>AppDataLocalQtMsBuildqt_tasks.targets.
! Be aware C:Users<username>AppDataLocalQtMsBuildqt_globals.targets is automatically generated every time visual studio is started. I coulnd’t find where the orginal 10000 came from so as a workaround, I decide to copy the modified version of the file on every build. !
To fix it, you could slow down the building process a lot by removing the /m argument when calling msbuild.exe. Though for it also worked to increase the timeout in the above file and defined the amount of threads building the project to 3.
msbuild.exe …. /m:3
Good luck!
I have periodically a report as
C:UsersAppDataLocalQtMsBuildqt_globals.targets(133,5): error : Qt::BuildLock[{]: Timeout; wait aborted [….vcxproj]
Then I call msbuild repeatedly and next build completed successfully.
Summary building is in two steps as two running of msbuild, first fail, second success.
Will try to remove /m option.
1