Windows Build system fails to track precompile header changes? I'm not sure I understand the issue. But sometime late last week (Friday) there was a change to the windows port which resulted in one of the win-ews instances failing. It seems to be a dependency tracking bug in the windows build. We need to fix all these sorts of dependency bugs for the long-term health of our bots. 3>DateInputType.cpp 3>..\platform\KURL.cpp : error C2220: warning treated as error - no 'object' file generated 3>..\platform\KURL.cpp : warning C4651: '/DENABLE_SANDBOX' specified for precompiled header but not for current compile 3>ColorCG.cpp 3>..\platform\sql\SQLValue.cpp : error C2220: warning treated as error - no 'object' file generated 3>..\platform\sql\SQLValue.cpp : warning C4651: '/DENABLE_SANDBOX' specified for precompiled header but not for current compile 3>..\html\DateInputType.cpp : error C2220: warning treated as error - no 'object' file generated 3>..\html\DateInputType.cpp : warning C4651: '/DENABLE_SANDBOX' specified for precompiled header but not for current compile Example failure: http://queues.webkit.org/results/4881029 Hopefully Adam or Lucas better remember what commit caused this error to start.
http://trac.webkit.org/changeset/70878 was probably the commit which caused the win-ews bot to start failing (and all other windows checkouts to require deleting their build directory!)
Yes, the problem is that changes to the .vsprops files don't force all precompiled headers to rebuild.
It would be nice to somehow fix the win-ews with some checkins here. And even better if we could fix the general problem with a build script or similar.
(In reply to comment #3) > It would be nice to somehow fix the win-ews with some checkins here. And even better if we could fix the general problem with a build script or similar. We already did checkins (see r70902, r70890, and r70884). I don't know why the EWS didn't benefit from them.
Lucas admin's the EWS instance which is currently failing to build. He might know better why the attempted fixes didn't catch that bot.
I wonder if not only precompiled headers, but also headers generated from *.in (ie. CSSPropertyNames and CSSValueKeywords) files can be handled on this bug as well?
Is this still actually a problem? https://trac.webkit.org/browser/trunk/Source/WTF/WTF.vcproj/work-around-vs-dependency-tracking-bugs.py?rev=111504 was meant to fix this kind of thing. If this *is* still a problem, we should put the fix in that script.