Making changes to win/tools/vsprops/FeatureDefines.vsprops does not trigger a reprocessing of some files (e.g. CSSPropertyNames.in) if they are indirectly affected. This leads to incremental builds (as those made by the EWS bots) to fail, because of class names missing. One example of this can be seen in #88645: the patch at https://bugs.webkit.org/attachment.cgi?id=146547 breaks the build (results here: http://queues.webkit.org/results/12917502 ), but touching Source/WebCore/css/CSSPropertyNames.in yields a successful build.
I'm facing the same issue, however I believe this bug is a duplicate of bug 38926?
(In reply to comment #1) > I'm facing the same issue, however I believe this bug is a duplicate of bug 38926? Indeed, it looks like a duplicate of #38926, but I don't think it's Chromium only...
(In reply to comment #2) > (In reply to comment #1) > > I'm facing the same issue, however I believe this bug is a duplicate of bug 38926? > > Indeed, it looks like a duplicate of #38926, but I don't think it's Chromium only... Yep, you can check bug 94094, for instance, where I upload a second, EWS-run only patch to test the code with the feature flag enabled, and you can see that gtk, win and mac builds gets failed because they don't renegerate headers for CSSPropertyNames.in and CSSValueKeywords.in. ps: Gustavo has open a bug that fixes the issue for gtk build (see bug 94927).